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ABSTRACT 


This  thesis  examines  the  viability  cf  a  microcomputer 
"based  process  which  allows  its  terminal  to  become  a  terminal 
to  a  remote  host  which  utilizes  the  UNIX  operating  system. 
The  means  of  communication  to  the  remote  host  is  an  Ethernet 
local  area  network. 

The  preponderance  -of  the  software  to  accomplish  the 
remote  login  is  PL/I  thus  enabling  the  software  to  be 
utilized  by  any  combination  of  computer/operating  system 
that  supports  PL/I.  The  Ethernet  driver  makes  use  of 
assembly  language  in  order  to  program  the  Ethernet 
Controller  Board  and  is  therefore  dependent  upon  the 
underlying  microprocessor. 

Although  the  communications  medium  is  the  Ethernet, 
ARPANET  Internet  and  Transmission  Control  protocols  are  also 
utilized.  This  is  necessitated  by  the  manner  in  which  the 
UNIX  operating  system's  remote  login  process  operates  and 
allows  the  far  more  general  case  where  the  remote  host  is 
part  of  the  ARPANET. 
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I .   INTRODUCTION 

A.   BACKGROUND 

AEGIS   is  a  highly  sophisticated  weapons  system  designed 
to   safeguard   a  surface  fleet  against   enemy  aircraft   and 


missiles . 


integral   part   of  the  system  is   the   SPY-1A 


radar;  it  feeds  its  data  to  a  Navy  standard  AN/YUK-7 
computer . 

The  AEGIS  weapons  system  simulation  project  is  an 
ongoing  study  being  conducted  at  the  Naval  Postgraduate 
School.  Its  primary  objective  is  to  study  the  feasibility 
of  replacing  the  present  four-processor  AN/YUK-7  mainframe 
computer  with  a  multi-microcomputer  based  architecture. 

The  AEGIS  weapon  system  must  process  in  real-time  large 
amounts  of  data  concerning  target  detection  and  acquisition. 
In  order  to  distribute  the  data  among  the  many  micro- 
computers, high  speed  data  communication  means  are  needed. 
The  high  speed  data  transfer  can  be  accomplished  by  tying 
clusters  of  MULTIBUS  connected  micro-computers  to  each  other 
by  means  of  a  local  area  network  such  as  Ethernet.  The  10 
megabit  per  second  data  transfer  rate  over  a  maximum  of  2500 
meters  of  cable  makes  Ethernet  a  powerful  data 
communications  medium  which  replaces  a  complex  system  of 
point  to  point  cables  with  a  single  cable. 
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In  order  to  create  a  useful  program  development 
environment  for  the  AEGIS  Modeling  Project,  it  is  convenient 
to  access  more  powerful  processors  located  outside  of  the 
micro-computer  cluster  out  connected  to  the  same  Ethernet. 
The  UNIX  operating  system  has  been  popular  on  mini-computers 
and  is  becoming  much  more  commonplace  on  the  newer,  more 
powerful  micro-computers  and  is  thus  a  natural  candidate  for 
a  remote  login  from  a  terminal  connected  to  the  micro- 
computer cluster. 

Initial   groundwork   in   the   AEGIS   project   for    the 

connection  of  micro-computers  to  more  powerful  processors 
using  the  Ethernet  was  conducted  by  Stotzer  [Ref.  1]  and 
Netniyom  [Ref.  2],  Stotzer,  working  at  the  micro-processor 
end,  and  Netniyom,  working  at  the  other  end  with  a  VAX 
11/763  VMS  operating  system,  implemented  message  passing  and 
file  transfer  routines.  As  VMS  did  not  provide  for  a  remote 
login  as  an  integral  part  of  the  operating  system,  the 
communication  terminated  at  the  VAX  end  in  one  of  the  device 
files,  thus  reauiring  one  "hard  wired"  terminal  from  the 
system.  A  hoped-for  virtual  communication  therefore  became 
in  essence  a  hard  wired  connection  over  the  Ethernet. 

B.   GENERAL  DISCUSSION 

The  Berkeley  4.2  version  of  the  UNIX  operating  system 
(4.2  BSD)  in  use  at  the  Naval  Postgraduate  School  runs  on  a 
V4.X   11/780  which  is  connected  to  an  Ethernet.    Since   this 
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version  of  UNIX  implements  networking  software  facilities, 
device  drivers  for  networking  hardware,  and  a  remote  login 
capability,  the  feasibility  of  remote  terminal  login  over 
Ethernet  to  a  more  powerful  remote  host  from  a  micro- 
computer was  investigated.  The  extension  beyond  Stotzer's 
and  Netniyom's  work  was  important  since  many  users  could 
remotely  use  the  VAX  11/780  over  just  one  communication 
medium,  Ethernet,  without  using  any  of  the  hardwired 
terminal  connections  to  the  remote  host.  The  method  of 
investigation  used  was  to  capture  for  analysis  the  Ethernet 
communications  between  a  Sun  Workstation,  running  4.2  BSD 
UNIX,  and  a  TAX  11/780,  also  running  4.2  BSD  UNIX. 

C.   STRUCTURE  OF  TEE  THESIS 

Chapter  I  presents  some  background  information  on  the 
AECIS  project  here  at  the  Naval  Postgraduate  School  and 
prior  work  to  facilitate  micro-computer  communication  with 
more  capable  processors  over  an  Ethernet  connection.  It 
also  discusses  the  continuing  effort  to  enhance  such 
communication  by  being  able  to  remotely  become  a  terminal  to 
a  VAX  11/780  from  a  micro-computer. 

Chapter  II  will  discuss,  in  a  rather  general  manner,  the 
topics  of  networks,  the  ARPANET  network,  and  the  relation 
between  the  ISO  standards  for  networks  and  the  manner  in 
which  the  ARPANET  is  implemented.  Information  of  local  area 
networks   and   Ethernet   will   also   be   presented.    Some 
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"background  knowledge  of  these  areas  is  necessary  since  the 
4.2  BSD  UNIX  system  implementation  of  the  remote  login 
allows  logging  in  over  a  long  haul  network  and  is  thus  more 
versatile  and  flexible  than  if  it  were  implemented  for 
logging  in  over  only  an  Ethernet. 

Chapter  III  covers  specific  information  on  the  MULTI3US 
system,  Ethernet  controller  "boards,  and  the  single  board 
computers  that  were  '  utilized  in  the  course  of  this 
investigati  on  . 

Chapter  IV  will  discuss  the  manner  in  which  the  two  UNIX 
"based  computers  communicate  over  the  Ethernet  when  remotely 
logging  in.  It  also  covers  in  detail  the  ARPANET  protocols: 
Internet  Protocol  (IP)  and  Transmission  Control 
Protocol(TCP) ,  the  UNIX  login,  terminal,  and  trailer 
protocols . 

Chapter  V  will  discuss  the  purpose  of  and  results 
obtained  by  the  demonstration  program.  It  will  also  discuss 
several  important  anomalies  that  must  be  avoided  should 
there  be  work  continuing  from  this  thesis. 

Chapter  VI  presents  the  conclusions  of  the  thesis. 
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II  .  NETWORKS 

A.   NETWORKS:  GENERAL  DISCUSSION 

1  •    3a ckground 

The  4.2  BSD  UNIX  implements  the  remote  login  in  a 
manner  that  is  general  enough  to  enable  one  to  login  to  a 
remote  host  computer  over  a  local  area  network  (LAN),  a  long 
haul  network  such  as  the  ARPANET,  or  any  combination  of  the 
two.  Thus  it  would  be  possible  to  remotely  login  from  one 
UNIX  system  to  another  by  using  a  local  area  network  to  a 
node  located  on  a  long  haul  network,  thence  over  the  long 
haul  network  to  a  remote  host  that  is  also  running  4.2  3SD 
UNIX.  In  such  a  case  the  remote  login  request  would  be 
surrounded  by  both  LAN  protocols  and  long  haul  network 
protocols,  specifically  ARPANET  protocols.  In  order  to 
analyze  the  remote  login  conversation  between  two  UNIX 
systems,  some  basic  knowledge  of  networks  is  necessary. 

2.    definition 

A  computer  network  is  an  interconnection  of 
autonomous  computers.  The  interconnection  can  be 
accomplished  by  a  variety  of  means  ranging  from  hardwired 
conections,  micro-wave  connections,  or  even  satellite 
connections;  in  fact,  some  large  networks  might  employ  all 
methods  of  connections  at  one  link  or  another  within  the 
network.    The   computers  should  be  thought  of  as  autonomous 
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in  that  there  is  no  master/slave  relationship  between  any  of 
the  computers  en  the  network. 

3«    A_i.rns  of  a  Network 

The  growth  of  networks  over  the  last  decade  has 
been  spectacular.  This  drift  away  from  large,  centralized 
computer  systems  is  caused  by  the  many  economic  and 
performance  advantages  of  networking.  3y  using  a  network, 
all  resources  (data,  programs,  processors,  etc.)  on  the 
network  are  potentially  available  to  anyone  using  the 
network  regardless  of  the  physical  proximity  of  those 
desired  resources.  Computing  systems  can  be  made  mucn  more 
reliable  with  the  utilization  of  networks  since,  should  one 
part  of  the  system  break  down,  other  parts  can  take  up  the 
load.  Thus  systems  can  degrade  in  capability  gracefully 
rather  than  catastrophi cally .  Since  the  cost  of  computers 
has  declined  dramatically  while  the  cost  of  communication 
has  remained  stable,  it  now  makes  more  sense  to  do  much  more 
processing  of  data  locally  and  then  communicating  only  the 
results  to  a  central  location  rather  than  sending  all  data 
to  a  central  point  for  all  processing  needs.  In  essence, 
the  tremendous  needs  generated  by  the  information  age  are 
more  easily  fulfilled  by  the  utilization  of  networks. 

*•   Networking  I§IHi 

Some  definitions  of  basic  networking  terms  are 
needed  before  continuing  the  discussion.  Hosts  are  the 
various   -nacbines  located  on  the  network  which  are   intended 
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for  running  user  (application)  programs.  The  specialized 
computers  that  perform  the  switching  necessary  in  a  network 
are  called  IMF's,  interface  message  processors.  A  link  is 
the  physical  communication  medium  used  to  pass  data  from  one 
IMP  to  the  next  IM?  in  the  network.  A  typical  session  on  a 
network  might  have  the  user  wanting  to  send  a  message  to 
another  person  in  a  distant  location.  The  user  would  sit 
down  at  his  host  computer  and  generate  his  message  which 
would  be  communicated  to  the  IMP  which  actually  puts  the 
message  onto  the  network  link  to  the  destination.  The  users 
data,  assuming  it  is  a  short  message,  would  he  transmitted 
across  the  network  in  a  p§£ket,  the  basic  unit  of 
information  that  moves  over  the  network.  A  packet  switched 
network  is  one  in  which  the  packet  can  very  greatly  in  size 
and  a  source  to  destination  path  need  not  be  established 
before  the  packet  is  sent  on  its  way.  For  instance,  two 
packets  from  the  same  host  to  the  same  destination  may  leave 
the  source  host  one  right  after  the  other  but  take  a 
different  route  to  the  destination  host.  The  first  packet 
transmitted  from  the  source  host  may  not  be  the  first  to 
arrive  at  the  destination. 
5*    Network  Layers 

Networks,  especially  long  haul  networks,  are  very 
complex  and  reauire  elaborate  software  to  make  them  run 
effectively.  In  order  to  allow  for  rapidly  changing 
technology   and  protocols,   the  design  of  software   must   be 
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very  modular  in  nature.  Also,  the  explosive  growth  of 
networks  has  made  the  adoption  of  standards  by  all  involved 
of  paramount  importance.  An  effort  to  simplify  production 
of  and  changes  to  neworking  software  by  standardizing  the 
modularity  of  the  software  is  found  in  the  seven  layered 
approach  as  espoused  by  the  International  Standards 
Organization  (ISO).  Figure  2.1  shows  the  ISO  standard  layer 
approach  to  communication  from  one  node  to  another  over  a 
network . 

Network  communication  commences  when  a  user  at  one  node 
interfaces  with  the  top  layer,  the  application  layer.  This 
layer  then  communicates  with  the  same  layer  in  the 
destination  node  by  what  is  called  a  peer  to  peer  protocol. 
A  protocol  is  a  communication  convention  between  equivalent 
layers  in  the  source  and  destination  hosts.  This  is  a 
virtual  communication;  actually  the  application  layer 
interfaces  with  and  makes  use  of  the  services  provided  by 
the  next  lower  layer,  the  presentation  layer.  This  layer 
communicates  to  the  presentation  layer  in  the  destination 
host  by  means  of  the  presentation  layer  peer  to  peer 
protocol.  As  before,  this  is  a  virtual  connection;  the 
actual  communication  by  the  presention  layer  is  to  the  next 
lower  layer.  The  actual  communication  continues  down 
through  the  layers  until  it  reaches  layer  1,  the  physical 
layer.  The  data  to  be  transferred  ends  up  at  the  lowest 
level   surrounded   by  various  extra  bits   appended   by   each 
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Figure  2.1     ISO  Network  Layers 


layer  as  the  lata  passes  through  it.  It  is  from  this  layer 
that  the  data  is  actually  moved  to  another  node  on  the 
network  by  some  physical  link,  hardwire,  microwave,  etc.. 
At  the  destination  node,  the  data  ascends  through  the 
layers,  losing  the  hits  added  by  the  source  node  layers, 
until  it  reaches  the  destination  application  layer.  Each 
layer  can  be  pictured  as  requesting  services  from  the  layer 
beneath  it  and  providing  services  for  the  layer  above  it. 

The  importance  of  this  layered  concept  is  that  functions 
associated  with  a  network  connection  can  be  grouped  together 
in  independent  software  modules  that  handle  only  the 
functions  of  one  particular  layer.  Should  the  peer  to  peer 
protocols  change,  then  only  the  one  software  module 
associated  with  that  layer  need  be  altered. 

6«    Elections  o£  ife^  L§Z§Ii 

The  first  of  the  seven  ISO  layers  is  the  physical 
layer.  Its  function  is  the  transmitting  of  raw  bits  of  data 
over  a  communication  channel.  The  protocol  at  this  layer 
must  ensure  that  if  the  source  transmits  a  binary  1,  then  a 
binary  1  is  received  at  the  destination.  It  accomplishes 
this  by  handling  electrical  voltages  and  electrical  pulses, 
cables,  and  connectors.  The  Ethernet  physical  layer  uses 
the  protocols  known  as  Carrier  Sense  Multiple  Acces(CSMA)/ 
Collision  Detection  (CD). 

The  function  of  the  data  link  layer  is  to  take  the  raw 
transmission  provided  by  the  physical  layer  and  transform  it 
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into  a  line  that  appears,  to  higher  protocols,  to  be  free  of 
transmission  errors.  This  layer  adds  flags  to  denote  the 
beginning  and  ending  of  messages,  utilizes  error  checking 
algorithms  are  utilized,  and.  distinguishes  data  from  flags. 
Also,  this  layer  deals  with  the  problems  of  acknowledgements 
and  of  flow  control  (a  fast  sender  swamping  a  slow 
receiver ) . 

The  function  of  the  network  layer  is  to  control  the 
operation  of  the  subnet,  the  lower  three  layers.  It 
determines  the  routing  to  the  destination,  prevents 
congestion,  and  breaks  large  packets  into  smaller  ones  if 
they  are  too  large  for  a  particular  link,  and  handles  flow 
control  within  the  network.  The  network  layer  may  provide 
either  iatagram  service  or  virtual  circuit  service. 
Datagram  service  delivers  to  the  next  higher  layer  the 
messages  from  the  transport  layer  without  ordering  the 
messages*  each  is  considered  an  isolated  unit.  The  virtual 
circuit  service  presents  the  transport  layer  with  ordered 
messages.  For  commercial  networks,  this  layer  contains  the 
accounting  algorithms  for  the  billing  of  customers. 

The  function  of  the  transport  layer  is  to  ensure  host  to 
host  error  detection  and  recovery,  control  the  size  of 
messages  passed  to  the  next  lower  level  (some  long  messages 
might  have  to  be  broken  up  into  shorter  length  messages), 
multiplex  the  end  user  address  onto  the  network,  and  the 
establishment /release  of  connections  across  the  network.   It 
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also   routes   incoming  messages  to  the   correct   process  or 

connections   within   the  host  and   reassembles   messages  by 

delivering  to  the  next  higher  level  the  parts  of  messages  in 

the  correct   order,   which  is  not  necessarily  the  order  in 
which  the  messages  were  received. 

The  session  layer  provides  the  users  interface  in  the 
network.  It  provides  the  establishment  of  a  connection  with 
a  process  on  another  machine.  Once  the  connection  has  been 
established,  it  controls  the  buffering  of  data,  the  data 
transfer,  and  the  graceful  or  abrupt  closure  of  the 
connect  ion . 

The  function  of  the  presentation  layer  is  to  negotiate 
the  syntax  for  characters  as  data,  text  strings,  terminal 
display  formats,  and  so  on.  This  layer  would  also  provide 
for  data  encryption  should  that  be  necessary. 

The  function  of  the  application  layer  is  largely 
determined  by  the  user.  It  can  provide  for  such  functions 
as  login  procedures  and  passwords.  Here  the  type  of  service 
to  the  user  is  defined;  i.e.,  is  the  transaction  a  file 
transfer,  data  transfer,  remote  login,  financial 
transaction ,  etc . . 


3.   THE  ARPANET 

1.    Background 

The   Department   of  Defense  started  the  funding   of 
research  into  computer  networks  during  the  1960's.    Through 
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the  Defense  Advanced  Research  Projects  Agency,  rroney  was 
provided  to  selected  universities  and  private  firms  to  set 
up  an  experimental  four  node  network.  It  became  operational 
in  1969.  It  has  since  expanded  to  over  130  nodes  that  span 
the  globe.  Eecause  of  the  length  of  time  it  has  been  in 
existence,  the  monies  provided  for  continuing  research,  and 
the  sponsorship  by  a  powerful  backer,  the  ARPANET  is  the 
most  significant  network  in  the  world.  Much  of  the  current 
day  knowledge  about  networks  can  be  traced  to  the  ARPANET 
development  . 

2.    ARPANET  Layers 

The  networking  layers  of  the  ARPANET  do  not 
correspond  in  a  one-to-one  manner  with  those  of  the  ISO 
standards.  Eigure  2.2  shows  the  ARPANET  layers  and  their 
relation  to  the  ISO  standard  layers.  The  ARPANET  protocols 
are  grouped  into  four  major  categories:  network  backbone, 
network  access,  host  to  host,  and  application  or  service 
protocols.  Each  of  these  is  independent  and  optimized  for 
its  special  function  and  may  contain  several  protocols 
embedded  . 

The  network  "backbone  protocols  are  the  IMP-IMP 
protocols,  routing  protocols,  and  end-end  protocols,  network 
access  protocols  define  the  interface  between  a  host 
computer  and  the  switching  nodes ( IMP 's  ) . 

The  above  protocols  are  interface  protocols  between 
IMP's   and   the  host  computer.    They  permit   reliable   data 
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transfer  into  or  out  of  the  IMP  to  the  host  link  or 
subnetwork.  These  two  protocols  do  not,  however,  provide 
reliable  host  to  host  peer  communication  across  the  network. 
This  all  important  function  is  provided  by  the  ARPANET 
internet  protocol  and  transmission  control  protocol,  IP/TCP. 
The  protocols  will  be  discussed  in  depth  later  in  this 
thesis?  they  form  the  major  part  of  the  communications 
format  that  takes  place  in  the  remote  login  facility  of  4.2 
BSD  UNIX.  A  less  robust  host  to  host  protocol  can  be  formed 
by  combining  the  same  internet  protocol  with  the  User 
Datagram  Protocol,  UDP.  This  protocol  provides  a  procedure 
for  application  programs  to  send  messages  to  other  programs 
with  a  minimum  of  protocol  mechanism.  It  is  transaction 
oriented,  and  delivery  and  duplicate  protection  are  not 
guaranteed.  Applications  that  reauire  an  ordered  delivery 
of  streams  of  data  should  use  the  TCP  vice  the  UDP  protocol. 
Above  these  layers  in  the  ARPANET  model  are  the 
application  or  service  layers  and  protocols  such  as  telnet 
(the  virtual  terminal  protocol),  ft?  (file  transfer 
protocol),  sftp  (simple  file  transfer  protocol),  etc.. 
Figure  2.3  shows  the  ARPANET  protocol   relationships. 

C.   LOCAL  AREA  NETWORKS 
1 .    Definition 

A   local   area  network  is  best  defined   by  listing 
some   of   the  requirements  that  are   generally   accepted   as 
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being  necessary  in  a  local  area  network.   It  is  a  collection 
of  automonous  computers  and  other  resources  that: 

a.  geographically  are  within  about  2500  meters  of  one 
another? 

b.  have   a   relatively   high   bandwidth,    usually 
ranging  from  1  to  10  million  bits  per  second; 

c.  low  cost; 

d.  capability   to   support   up  to   several   hundred 
connections  of  devices  on  the  network; 

e.  low  error  rates,  high  reliability,  and  independence 
from  a  centralized  control; 

f.  ease  of  installation  and  extensibility; 
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2»    Why  local  Area  Networks 

There  are  several  reasons  for  the  high  interest  in 
local  area  networks.  Organizations  today  may  have  many 
computers  and  peripherals  located  within  the  same  or 
adjacent   buildings.   Cost   and   performance   considerations 
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demand  that  most  if  not  all  of  these  devices  be  tied 
together  over  some  communicat ion  medium.  The  most  efficient 
manner  of  interconnection,  rather  than  a  maze  of  "hardwired" 
connections,  is  a  local  area  network  utilizing  a  high 
bandwidth  physical  cable.  Each  computer  or  peripheral  is 
then  attached  to  the  channel  over  a  very  short  physical 
connection.  a  distinct  advantage  of  a  local  area  network  is 
its  ability  to  more  effectively  and  efficiently  perform 
distributed  computing  tasks.  This  allows  specific  functions 
such  as  file  storage,  data  base  management,  terminal 
handling  and  so  on  to  be  assigned  to  specific  machines  thus 
simplifying  implementation. 

Local  area  networks  have  several  factors  that  make 
their  implementation  nuch  easier  than  long  haul  networks. 
The  routing  algorithms  can  be  as  simple  as  broadcasting  all 
messages.  The  routing  algorithms  on  long  haul  networks  can 
become  extremely  complex,  especially  when  one  network  is 
tied  into  other  networks.  Local  area  networks  do  have 
potential  congestion  problems,  but  they  are  minor  compared 
to  those  that  can  be  encountered  on  long  haul  networks. 

Local  area  networks  can  sense  congestion  because  they 
sense  the  state  of  the  broadcast  channel  before  attempting 
to  use  it.  Two  of  the  types  of  local  area  networks  are  the 
carrier  sense  networks  and  the  ring  networks!  each  type  has 
a  unique  method  of  sensing  the  state  of  the  network.  The 
carrier  sense  method,   when  it  has  data  to  send.   listens  to 
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the  channel  to  see  if  anyone  else  is  broadcasting.  If  the 
channel  is  busy,  the  station  waits  until  the  channel  becomes 
idle.  Once  it  has  sensed  an  idle  channel,  it  transmits  all 
or  part  of  its  data  in  a  packet.  If  a  collision  occurs  with 
another  unsensed  packet,  thus  corrupting  the  transmission, 
the  station  waits  a  random  amount  of  time  and  then  starts 
the  process  over  again.  The  ring  networks,  like  the  carrier 
sense  networks,  use  twisted  cable,  coaxial  cable,  or  fiber 
optics  as  the  transmission  medium?  however,  the  ring  net  is 
a  series  of  point  to  point  cables  between  consecutive 
stations.  The  basic  method  of  the  control  of  network 
congestion  is  through  a  token  system.  Each  node  wishing  to 
transmit  must  have  a  ticket  or  token  in  order  to  use  the 
network . 

3.    Ethernet 

Ethernet  is  a  local  area  network  specification 
developed  by  Digital  Equipment  Corporation,  Xerox 
Corporation,  and  Intel  Corporation.  It  is  designed  for  the 
high  speed  data  exchange  among  computers  and  other  digital 
devices  located  within  a  moderately  sized  geographical  area. 
The  Ethernet  specification  pertains  to  the  first  two  layers 
of  the  ISO  model,  the  physical  and  data  link  layer.  It 
provides  for  a  data  transmission  rate  of  1?  million  bits  per 
second  over  a  coaxial  cable  with  a  maximum  length  of  2.8 
kilometers.   It  supports  up  to  1024  stations  with  a  topology 
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of   a   branching  non-rooted   tree.    The   link   control   is 
CSKA/CD. 

4«   Ethernet  Frame  Format 

a.  General 

The  Ethernet  frame  consists  of  the  following 
five  fields:  the  destination  address,  the  source  address, 
the  type  field,  the  data,  and  finally  the  frame  check 
seauence.  The  64  bit  preamble  used  for  receiver 
synchronization   is  not  available  to  the   user. 

b.  Destination  address 

The  six  byte  destination  can  be  one  of  three 
types  of  addresses.  It  can  be  the  physical  address  of  a 
board;  this  address  is  unique  to  each  board  interfacing  on 
the  Ethernet;  its  first  three  bytes  are  assigr.ed  by  Xerox 
and  the  last  three  by  the  board  manufacturer.  It  could  also 
be  a  multicast  address;  this  board  can  be  user  programmed  to 
contain  up  to  64  different  multicast  addresses.  All  boards 
receive  broadcast  packets. 

c  .    Source  address 

The  physical  source  of  the  particular  board  is 
automatically   inserted  upon  packet  transmission.    This  can 
be  circumvented,  as  will  be  explained  later, 
d.    Type  field 

The  two  byte  type  field  contents  are  not 
specified;  the  user  can  use  it  for  whatever  purpose  he 
desi  res . 
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e.  Data  field 

The  data  field  must  be  a  minimum  of  -±6  bytes 
and  can  be  as  long  as  1500  bytes.  Should  the  user  data  be 
less  than  45  bytes,  the  unused  bytes  are  stuffed  with  the 
null  byte. 

f.  Frame  check  sequence 

This  is  a  32  bit  cyclic  redundancy  check  of 
the  Fthernet  frame  from  the  destination  address  down  to  the 
last  byte  of  data. 
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III.   NPS  FACILITIES 

A.   BACKGROUND 

The  system  used  at  the  Naval  Postgraduate  School  to 
investigate  the  viability  of  the  remote  login  over  Ethernet 
was  composed  of  the  following  components:  the  AEGIS  Project 
multi-user  system,  a  Sun  Workstation  and  a  TAX  11/780,  "both 
running  4.2  BTS  UNIX.  All  components  of  the  system  were 
connected  "by  an  Ethernet.  Figure  3.1  shows  an  overview  of 
the  system.  The  makeup  of  the  AEGIS  multi-user  system  is 
shown  in  Figure  3.2.  Its  MULTIBUS  "backplane  contains  four 
Intel  86/12  Single  Beard  Computers,  two  additional  memory 
hoards,  and  an  Interlan  Ethernet  Controller  Board.  Each 
86/12  SBC  is  attached  to  its  own  terminal.  Secondary 
storage  for  the  system  is  provided  by  two  hard  disk  drives 
and  two  floppy  disk  drives.  Some  basic  knowledge  of  the 
multi-user  system  components  is  necessary  for  the 
understanding  of  the  programs  contained  in  this  thesis. 

E.   MULTI-USER  SYSTEM  COMPONENTS 

1-    Inl§I  86/12  Single  Board  Computer 

The  86/12  SBC  contains  all  the  components  necessary 
for  a  computer  on  a  single  board!  it  contains  an  6086  16-bit 
microprocessor,  64K  bytes  of  onboard  RAM,  a  serial 
comnunicat ions  interface,  a  programmable  interrupt 
controller,   and  a  programmable  timer..  It  also  contains  the 
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circuitry  necessary  for  the  use  of  the  "board  on  a  MULTIBUS 
system.  The  board  is  configured  so  that  it  can  act  either 
as  a  MULTIBUS  slave  hoard  or  as  a  master  board  and  can 
accept  user  provided  ROM  of  up  to  32K  bytes.  All  of  the 
onboard  RAM  is  accessible  to  offboard  components  if  the 
board  is  unstrapped;  or,  conversely,  none  of  the  onboard 
memory  can  be  accessed  from  offboard  components  if  the  board 
is  strapped.  The  ability  to  allow  or  disallow  access  to 
onboard  memory  (strapping)  is  a  convienent  feature  of  the 
SEC  that  makes  it  very  useful  in  multi-processing 
installations.  In  the  AEGIS  system,  the  boards  are  strapped 
to  ensure  that  no  process  running  on  another  board 
accidentally  contaminates  the  onboard  memory  of  another 
board. 

The  8086  was  one  of  the  first  commercially  available  16- 
bit  microprocessors.  Figure  3.3  shows  the  internal  structure 
of  the  8086.  The  processor  is  divided  into  an  execution 
unit,  SU,  and  a  bus  interface  unit,  EIU.  The  EU  implements 
a  standard  single-bus,  accumulator  based  arhitecture  and  the 
BIU  manages  all  bus  communications  to  the  outside  world.  The 
data  and  addresses  are  multi-plexed  over  the  same  16  pins  of 
the  40  pin  chip.  The  BIU  also  implements  an  instruction 
pipeline  in  order  to  speed  up  the  execution  in  the  80S6.  Up 
to  six  pre-fetched  instructions  are  queued  for  execution. 
General  use  registers,  the  AX,  BX,  CX,  and  DX  registers,  are 
16  bits  wide  and  are  either  8  or  16  bit  addressable.   There 
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are  also  four  word  addressable  registers  for  indicies  and 
pointers,  the  CS(code  segment),  the  DS(data  segment),  the 
SS(stack  segment),  and  the  ES(extra  segment).  These  segment 
registers  serve  as  "base  addresses  for  addressing  64K  byte 
segments  within  the  20  bit,  one  megabyte  address  space  of 
the  8086.  In  order  to  effectively  address  one  megabyte,  the 
base  address,  only  16  bits,  is  left  shifted  by  four  bits  so 
that  when  added  to  the  16  bit  offset,  the  full  one  megabyte 
address  space  is  available.  These  segment  registers  are 
programmable  so  that  any  portion  of  the  one  megabyte  address 
space  is  available.  This  enables  the  addressing  of  memory 
space  which  lies  outside  the  64K  of  86/12  SBC  onboard  RAM. 
This  is  crucial  for  the  ability  to  address  the  memory 
expansion  boards  and  other  offboard  components  as  part  of  6 
process  running  en  the  86/12  SBC. 

2.    Memory.  Configuration  on  the  MULTIBUS  System 

The  AEGIS  project  makes  use  of  a  multi  user  system 
to  run  a  multiprocessing  operating  system,  MCOPTEX ,  which 
is  appended  to  the  CPM-86  operating  system  that  is  resident 
on  each  86/12  SBC.  MCORTEX  is  loaded  from  disk  directly  to 
onboard  memory.  CPM-86  has  a  master  and  a  slave  version. 
The  master  version  is  loaded  from  disk  to  the  MULTIBUS 
master  86/12  SBC.  The  slave  version  is  loaded  onto  a  memory 
expansion  board  called  common  memory?  copies  of  this  are 
then  loaded  into  slave  86/12  SBC's  as  needed.  This  common 
memory  belongs  to  all  boards  and  processes  and  is  the   area 

35 


where  MCORTEZ  places  various  process  synchronization  data. 
The  other  memory  expansion  board,  call  it  the  extended 
T?A( transient  program  area),  is  available  to  any  36/12  SBC. 
For  the  purposes  of  this  thesis,  this  extended  TPA  was  used 
"by  the  PL/I  programs  as  a  portion  of  the  data  segment  from 
and  to  which  the  Direct  Memory  Access  operations  for  the 
Ethernet  Control  Board  were  conducted.  Figure  3.4  depicts 
in  a  linear  manner  the  memory  utilization  in  the  ASC-I3 
multi-user  system. 

3-    l^ter Ian  ^13013  Ethernet  Controller  Board 
a.    General 

The  Ethernet  controller  Board  is  a  MULTIBUS 
Ethernet  communications  controller  that  together  with  a 
transceiver  implements  layers  one  and  two  of  the  ISO  network 
layer.  It  implements  fully  a  protocol  that  complies  with 
the  Xerox/Intel/Digi tal  Ethernet  specification,  version  1.0. 

The  hoard  performs  data  link  layer  functions  by 
formatting  user  data  into  frames  and  performing  the  CSMA/CD 
sensing.  It  automatically  provides  the  cyclic  redundancy 
code  generation  (CRC  code).  The  board,  when  listening  to 
the  network,  recognizes  and  accepts  frames  which  are 
addressed  to  the  board's  physical  address,  one  of  its  multi- 
cast addresses,  or  any  broadcast  frame. 

The    controller   board   performs   the   physical    layer 
functions   by   transmitting/receiving  bit   streams   at   1? 
megabytes  per  second.   It  also  contains  a  16K  receive  buffer 
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so  that  the  host  computer  can  "read  the  incoming  frames  or 
packets  at  its  own  convenience.  By  "buffering,  it  also 
shields  the  MULTIBUS  from  the  unpredictable  arrival  time  of 
frames.  The  NI3010  board  has  the  DMA  controller  that  moves 
packets  to/from  host  memory.  The  board  has  control  of  the 
MULTIBUS  during  this  transfer.  Should  another  board  take 
over  the  MULTIBUS  between  data  transfers,  the  NI3012  board 
will  resume  its  DMA  transfer  from  the  point  where  it 
surrendered  the  bus.  The  board  also  maintains  a  small  buffer 
2K  in  length  for  a  storage  of  data  to  be  transmitted.  In 
the  programs  included  herein,  the  NI301Z  performs  DMA 
transfers  to/from  the  extended  T?A  memory  board.  The  NI3210 
board  also  performs  extensive  self-diagnostics  and  can  keep 
statistics  on  the  network  traffic  and  errors, 
b.    Frame  transmission 

The  host  computer  sets  up  in  contiguous  memory 
a  transmit  data  area  in  the  extended  T?A.  When  instructed 
by  the  host,  the  NI3010  board  commences  a  DMA  transfer  of 
this  data  into  its  transmit  buffer.  The  board  does  not 
attempt  transmission  onto  the  network  until  specifically 
told  to  do  so  by  the  host.  Once  instructed  to  do  so,  it 
inserts  the  source  address  of  the  board,  computes  and 
appends  the  CRC,  and  transmits  the  packet.  Should  a 
collision  occur  that  prevents  transmission,  the  board  will 
automatically  attempt  to  retransmit  up  to  16  times.  Figure 
3.5   shows   the   format  of  the  transmit   data   area. 
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figure  3.5       Transmit  Data  Block 


c.    Frame  receptions 

When  the  NI3010  receives  a  packet  that  is 
destined  for  its  host,  it  informs  the  host  via  a  hardware 
interrupt.  When  the  host  decides  it  is  ready  for  the  packet, 
it  signals  the  board  which  then  prefixes  frame  status  and 
frame  length  information  to  the  received  frame,  and  then 
performs  a  DMA  transfer  of  the  packet  into  a  host  determined 
area  of  memory.  In  the  AEGIS  project,  it  is  transferred  to 
the  extended  TPA  portion  cf  memory.  Figure  3.6  shows  the 
fornat  of  a  packet  that  has  teen  transferred  to  the  receive 
data  area. 
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Receive  Data  Block 
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IV.   REMOTE  LOGIN  PROTOCOLS 


A.   UNIX  REMOTE  LOGIN 

1 .   What  is  a  gemote  L^gin 

When  a  user  desires  to  remotely  log  into  the  VAX 
from  the  Sun  Worksation,  he  executes  the  UNIX  command 
RLOGIN.  The  Sun  then  sends/receives  packets  over  the 
Ethernet  to/from  the  VAX  login  port.  The  terminal  attached 
to  the  Sun  appears  to  the  user  as  if  it  were  hardwired 
directly  into  the  VAX.  All  of  the  networking 
implementations  are  transparent  to  the  user.  All  of  the 
normal  login  messages  and  terminal  queries  appear,  as  does 
the  same  command  line  prompt  used  on  the  VAX  UNIX.  All 
special  control  characters,  such  as  'kill'',  'delete',  etc., 
are  exactly  as  those  used  on  the  VAX.  Investigating  the 
viability  of  duplicating  this  process  on  the  AEGIS  multiuser 
system  is  the  goal  of  this  thesis. 

2-    ?§cket  Contents 

The  first  step  taken  in  investigating  the  UNIX 
remote  login  processs  was  to  produce  a  program  for  the  AEGIS 
project's  multiuser  system  that  passively  listened  in  on 
the  Ethernet  and  captured  the  conversation  "between  the  VAX 
and  the  Sun  when  remotely  logging  in  and  conducting  a 
terminal  session.  The  program,  LISTEN,  captured  all  traffic 
on  the  Ethernet  and  printed  it  into  a  file  in  either 
hexadecimal  or  binary  format.    Since  the  Ethernet  cable  had 
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only  three  devices  connected  to  it  at  the  time,  it  was 
possible  to  eliminate  all  traffic  on  the  cable  except  these 
packets  that  were  directly  involved  with  this  remote 
login/terminal  process. 

Examination  of  the  packets  revealed  that  several 
protocols  were  present.  The  most  obvious  protocol  was  the 
Ethernet  protocol.  The  only  item  of  interest  here  as  far  as 
the  remote  login  was  the  Ethernet  header  type  fields.  As 
mentioned  in  Chapter  II,  this  field  is  undefined  in  the 
Ethernet  specifications  and  is  available  to  the  user  for 
whatever  use  he  deems  appropriate.  In  this  case,  the  low 
order  byte  of  the  type  field  was  always  S  hexadecimal  and 
the  high  order  byte  was  0.  The  reason  for  this  is  not  known 
to  the  author. 

There  were  two  ARPANET  protocols  present,  the  Internet 
and  TCP  protocols.  There  were  also  UNIX  login,  terminal, 
and  trailer  protocols.  The  login  and  terminal  protocols  are 
very  similar  to  those  used  during  a  normal  login  session 
when  a  terminal  is  hardwired  into  the  VAX  UNIX.  The 
conversation  over  the  Ethernet  can  be  viewed  as  protocols 
wrapped  in  protocols.  The  Ethernet  protocols  are  the 
outermost  layer,  then  Internet  and  TCP,  then  the  UNIX 
protocols . 

At  first  glance  it  appears  that  there  is  a  lot  of  excess 
baggage  used  to  merely  become  a  terminal  over  the  Ethernet. 
However,    the   implementation   used   by   4.2   BSD   UNIX   is 
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sufficiently  general  so  that  the  remote  login  could  take 
place  from  the  Sun,  over  the  Ethernet  to  the  VAX,  and  then 
over  the  ARPANET  to  another  node  running  4.2  3SL  UNIX .  A 
much  less  complex  method  could  have  been  implemented,  out  it 
would  not  have  complied  with  ARPANET  specifications. 
Besides,  since  there  is  a  large  bandwidth  available  on  the 
Ethernet,  these  extra  bytes  take  up  little  "space". 

E.   INTERNET  PROTOCOL 

1 .    Background 

The  Internet  Protocol  (IP)  was  developed  for  use  in 
packet  switched,  interconnected  networks.  The  fundamental 
purpose  of  IP  is  to  transfer  data  from  one  host  to  another 
over  a  long  haul  network  and  to  allow  long  blocks  of  data  to 
be  broken  up  into  smaller  pieces  (fragmentation)  should  a 
particular  link  in  the  network  not  be  able  to  handle  that 
sized  block  of  data.  The  block  of  data  transferred  by  I?  is 
referred  to  as  a  datagram.  The  I?  datagram  consists  of  two 
elements,  a  header  and  the  actual  data.  The  scope  of  this 
protocol  is  limited;  it  does  not  provide  for  end  to  end 
reliability,  flow  control,  sequencing,  or  other  host  to  host 
protocols.  These  later  functions  are  the  objects  of  the  next 
higher  protocol,  TCP. 

Figure  2.2  shows  the  relation  of  IP  to  the  other 
ARPANET  protocols.  The  layering  indicates  that  the  IP  would 
be  called  upon  to  provide  services  for  the  next  higher 
protocol,   TCP,   and  to  call  upon  the  network  interface   for 
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services  recuired  by  I?.  In  the  remote  login  process,  the 
TCP  segment (header  and  possibly  data)  is  the  data  portion  of 
the  IP  datagram.  IP  would  then  call  on  an  Ethernet  device 
driver  to  transmit  the   I?  datagram.   At  the  receiving  host, 

there  must  he  an  IP  protocol  layer  that  properly  interprets 
the  header  information  for  its  next  higher  layer. 

When  a  user  wants  to  send  data  to  a  remote  station  on  a 
long  haul  network,  he  provides  the  application  layer  with 
the  name  of  the  desired  destination.  It  is  the  job  of 
layers  above  IP  to  map  or  change  that  name  into  a  network 
address.  IP  needs  to  know  the  "where"  of  the  destination 
rather  than  the  "who".  IP  depends  upon  lower  level  modules 
to  provide  the  route  for  its  datagram  to  follow  across  the 
network. 

2«    12   Specification 

Figure  4.1  shows  the  I?  header  format.  A 
discussion  of  the  fields  follows.  The  version  field  is  four 
bits  long  and  shows  the  version  number  used  for  the 
information  contained  in  this  header.  The  current  version 
of  IP  header  is  4.  The  IHL  field,  4  bits,  is  the  length  of 
the  internet  header  in  32  bit  words  and  is  used  to  determine 
where  the  IP  data  bytes  begin  in  the  datagram.  The  minimum 
length  of  the  I?  header  is  5.  In  the  remote  login  process, 
the  IHL  is  always  5  (20  bytes  of  header).  The  type  of 
service  tells  how  the  datagram  is  to  be  treated  during  its 
trip    throughout   the   network   (how   important    is    this 
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Figure  4.1     Internet  Header  Format 
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datagram).  The  remote  login  process  uses  only  00  in  this 
field  which  indicates  normal  delay,  reliability,  and 
throughput  and  routine  precedence  (as  opposed  to  priority, 
immediate,  flash,  etc.).  The  total  length  field  is  the 
total  byte  count  of  the  datagram,  header  and  data.  The  two 
byte  field  allows  a  length  of  65,535  bytes,  but  this  is 
impractical  for  most  hosts  and  networks.  All  hosts  must  be 
able  to  receive  datagrams  of  at  least  575  bytes. 

Fragmentation  is  not  really  an  issue  when  remotely 
logging  in  over  an  Ethernet  to  a  host  which  is  attached  to 
the  same  Ethernet.  The  length  of  the  data  field  in  the 
Ethernet  packet,  up  to  1500  bytes,  is  quite  adequate  to 
accomodate  the  protocols  and  data  that  are  used  in  the 
remote  login/terminal  process.  Fragmentation  does  become  an 
issue  when  the  remote  login  packet  must  cross  long  haul 
networks.  The  next  three  fields  deal  with  fragmentation. 
The  observed  packets  always  had  the  identification  bytes  set 
to  some  host  determined  unique  number  associated  with  a 
particular  source-destination  pair  and  protocol  for  the  tine 
the  datagram  could  be  alive  in  the  network.  That  value  was 
incremented  by  01  hexadecimal  with  each  packet  sent  by  a 
particular  host.  The  flags  field  was  always  00  hexadecimal 
indicating:  each  packet  may  be  fragmented  and  that  this 
particular  packet  was  the  last  fragment  (which  matches  with 
the  identification  field  increasing  by  01  hexadecimal  with 
each   packet).   The  fragment  offset  indicates  where  in   the 
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original  datagram  this  fragment  belongs  and  thus  was 
observed  to  always  be  00  hexadecimal  in  the  remote  login 
process . 

The  time  to  live  field  indicates  the  maximum  time  the 
datagram  is  allowed  to  remain  in  the  Internet  system.  Its 
purpose  is  to  cause  undeli verable  datagrams  to  be  discarded 
and  to  bound  the  maximum  datagram  lifetime.  As  with 
fragmentation,  this  field  is  necessary  if  the  packet  must  be 
sent  over  a  long  haul  network.  The  observed  value  was 
always  07  hexadecimal.  When  remotely  loging  into  a  host  on 
the  same  Ethernet,  this  field  must  contain  a  value  of  at 
least  01  hexadecimal  because  the  IP  specifies  that  packets 
with  this  field  reading  00  hexadecimal  are  to  be  destroyed. 

The  protocol  field  always  reads  06  hexadecimal  which 
indicates  that  the  next  higher  protocol  used  in  the  data 
portion  of  the  datagram  is  TCP.  The  header  checksum  is  a 
checksum  for  the  IP  header  only.  It  provides  for  high 
reliability  in  the  communications.  In  the  remote  login 
process  since  TCP  and  its  data  form  the  data  portion  of  IP, 
and  this  is  all  covered  by  the  TCP  checksum,  the  entire 
communication  is  covered  by  a  checksum.  The  official 
wording  of  the  checksum  algorithm  is  "....  the  16  bit  one's 
complement  of  the  one's  complement  sum  of  all  16  bit  words 
in  the  header.  For  purposes  of  computing  the  checksum,  the 
value  of  the  checksum  field  is  zero.' [Ref.  3]  See  Appendix 
F  of  this  thesis  for  further  elaboration  on  the  checksum. 
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The  source  address  and  destination  address  fields  are 
grouped  into  three  classes,  class  a,  b,  or  c.  The  class 
that  was  obsserved  in  the  remote  login  process  was  the  class 
c  address.  The  class  is  not  a  function  of  the  remote  login 
process;  it  is  the  address  of  the  Naval  Pos trgraduate  School 
on  the  ARPANET.  The  class  c  address  has  three  bytes  of 
network:  address  and  one  byte  for  the  local  address.  The 
network  address  of  the  VAX  is  c0  09  c8  03  hexadecimal,  with 
the  03  indicating  its  local  address.  The  Sun  Workstation 
address  is  c0  09  c3  01  hexadecimal.  The  list  of  all  valid 
hosts  to  which  a  particular  UNIX  implementation  can  talk  can 
he  found  in  the  UNIX  file  '/etc/hosts" ;  the  addresses  appear 
in  decimal  form,  not  hexadecimal. 

G.   TRANSMISSION  CONTROL  PROTOCOL 
1 .    l§_ckgr  ound 

The  Transmission  Control  Protcol  (TCP)  was  designed 
to  he  used  as  a  highly  reliable  host  to  host  protocol 
in  packet-switched  networks  and  in  interconnected  systems  of 
such  networks.  It  provides  for  reliable  inter-process 
communication  between  pairs  of  processes  in  host  computers. 
The  protocol  makes  few  assumptions  concerning  the 
reliability  of  the  protocols  which  belong  to  lower  level 
layers.  It  is  designed  to  operate  above  a  wide  spectrum  of 
networks  be  they  hardwired,  packet  switched,  or  circuit 
swit  ched . 
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Figure  2.2  shows  the  position  of  TC?  in  the  ARPANET 
network  layers.  TCP  would  he  called  upon  "by  higher  level 
protocols  to  provide  service  for  then?  and  TCP  would  in  turn 
call  upon  Internet  for  services.  Whatever  lata  or  control 
"bytes  come  to  it  from  a  higher  layer  would  he  added  to  the 
TCP  header  as  data  and  passed  to  the  IP  layer.  The  TCP 
healer  and  its  data,  if  any,  is  called  a  segment,  and  it 
forms  the  data  portion  of  an  I?  datagram  in  the  remote  login 
process.  The  destination  host  must  also  contain  a  protocol 
that  recoginizes  and  evaluates  the  information  contained  in 
the  TCP  segment. 

The  TCP  performs  its  services  to  higher  protocols  hy 
providing  mechanisms  that  ensure  data  transfer,  reliability, 
flow  control,  multiplexing,  and  connections.  TC?  allows  a 
continuous  flow  of  data  to/from  each  host.  In  general,  a  TCP 
would  block  and  forward  data  at  its  own  convenience,  hut 
there  are  certain  times  when  a  user  must  know  that  the  iata 
that  has  been  sent  to  the  TC?  has  been  transmitted.  This 
user  determined  transmission  of  iata  is  called  a  "push". 
For  instance,  in  the  remote  login/terminal  process,  the  user 
forces  or  "pushes"  the  transmission  of  his  UNIX  command  by 
the  use  of  the  carriage  return  key. 

TCP  can  recover  from  data  that  is  damaged,  lost, 
duplicated,  or  delivered  out  of  order.  This  is  achieved  by 
assigning  a  sequence  number  to  each  byte  of  data 
transmitted,    and   requiring  positive   acknowledgement   cf 
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reception  from  the  receiving  TCP.  If  not  acknowledged,  the 
segment  is  retransmitted  after  a  certain  time  interval. 
These  sequence  numhers  also  allow  the  receiving  host  to 
order  incoming  packets  so  that  they  are  provided  to  the  next 
higher  layer  in  the  proper  order.  Damaged  packets  are 
handled  by  adding  a  checksum  for  the  TCP  segment;  damaged 
packets  are  not  processed.  TCP  is  extremely  robust.  It 
provides  recovery  from  any  communications  errors,  providing 
the  TCP  is  itself  functioning. 

TCP  handles  the  problem  of  a  fast  sender  swamping  a  slew 
receiver,  flow  control,  by  use  of  the  window  field.  The 
window  on  an  incoming  segment  indicates  an  allowed  number  of 
bytes  that  the  receiver  may  transmit  before  receiving 
further  permission.  The  window  governs  not  how  many  packets 
are  sent  per  unit  of  time,  but  how  much  data  can  be  sent  at 
any  given  t  ime . 

TCP  allows  for  many  processes  within  a  single  host  to  be 
communicating  with  the  same  remote  host  simultaneously  by 
providing  a  set  of  addresses  within  each  host  called  ports. 
This  port  address,  when  concatenated  with  a  network  and  host 
address  form  what  the  ARPANET  terms  a  socket.  k  pair  of 
sockets,  one  in  each  host,  uniquely  identifies  what  is 
termed  a  connection.  A  connection  is  the  process  to  process 
service  provided  by  TCP.  In  the  remote  login  process,  each 
successful  login  to  the  remote  host  would  form  a  separate 
connection   from   the  user  to  the  remote  login  port   of   the 
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VAX.  Since  the  login  process  itself  handles  many  users, 
many  user  could  log  in  over  the  ithernet  to  the  remote  login 
port.  This  can  be  demonstrated  "by  using  the  Sun  Workstation 
to  log  into  the  VAX  system,  then,  using  that  connection,  to 
remotley  log  "back  into  the  Sun,  in  turn  using  this  new 
connection  to  remotely  log  into  the  VAX  again,  ard  so  on. 
Since  connections  must  be  established  between  unreliable 
hosts  over  unreliable  networks,  a  handshake  mechanism  witn  a 
clock-based  sequence  number  int ializat ion  is  used  to  prevent 
erroneous  initialization  of  connections. 

2.    TCP  Specification 

TCP  segments  (header  and  data)  are  sent  as  part  of 
an  I?  datagram?  the  TCP  header  immediately  follows  the  IP 
heaier.  Figure  4.2  shows  the  format  for  the  TCP  header.  An 
explanation  of  the  fields  now  follows. 

The  source  port  and  destination  port  fieleds  are  used  by 
TCP  so  that  it  may  uniquely  identify  separate  streams  of 
data.    This  address,  along  with  the  address  fields  from  the 


IP  header  form  the  address 


the  lata  stream  that  uniquely 


identifies  it  throughout  the  network.  The  port  address  for 
the  UNIX  login  port  is  02  01  hexadecimal  (513  decimal);  a 
listing  of  this  port  address  and  all  network  services  port 
addresses  can  be  found  in  the  UNIX  file  "/etc/services". 
UNIX  evaluates  all  source  norts  of  inbound  packets  to  see  if 
they  are  between  0  to  03  ff  hexadecimal.  Thus  in  the 
initial  login  request  from  the  Sun  Workstation,   the   source 
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figure  4.2     TCP  deader  Format 
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port  is  03  ff  hexadecimal  ani  the  destination  port  is  02  01 
hexadecimal.  Should  multiple  users  desire  to  los  into  the 
VAX  from  the  Sun  Workstation,  each  would  use  a  destination 
port  address  of  02  01  hexadecimal,  hut  each  would  use  a 
separate  source  address  between  0  and  03  ff  hexadecimal. 
This  would  uniauely  identify  each  TCP  connection  and  hence 
each  separate  login. 

The  sequence  number  field  is  a  32  bit  number  that  refers 
to  the  first  data  byte  in  the  data  portion  of  that 
particular  TCP  segment.  If  there  is  no  data  present  in  the 
TCP  segment,  such  as  in  the  case  of  acknowledgement  only 
packets,  then  the  sequence  number  refers  to  the  data  byte 
that  will  next  be  sent  by  that  socket.  Since  every  byte  of 
data  is  assigned  a  sequence  number,  the  segment  sequence 
number  is  the  lowest  unused  number  in  the  32  bit  sequence 
number  space.  The  acknowledgement  number  field  in  a  TCP 
see:mert  is  the  sequence  number  of  the  next  expected  data 
byte  of  transmission  in  the  reverse  direction.  Since  every 
byte  of  data  has  a  sequence  number,  each  of  them  can  be 
acknowledged.  The  simplest  form  of  the  acknowledgement 
procedure  is  to  make  it  cumulative  so  that  an 
acknowledgement  number,  call  it  X,  indicates  that  all 
sequence  numbers  up  to,  but  not  including  X,  have  been 
received.  The  initial  seauence  number  is  chosen  based  on  a 
clock  based  algorithm.  This  enables  TCP  to  detect  duplicate 
packets   from  a  previous  instance  of  the  connection.    It  is 
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important  to  note  that  a  pure  acknowledgement  packet  dees 
not  contain  data  and  hence  does  not  occupy  sequence  number 
space . 

The  data  offset  field  is  the  number  of  32  hit  words  In 
the  TCP  header.  The  reserved  field  is  reserved  for  future 
use  and  is  filled  with  0's.  Each  hit  in  the  control  field 
informs  the  TCP  of  a  particular  kind  of  event;  each  event 
requires  different  processing  depending  upon  in  which  state 
the  TCP  is.  More  on  TCP  states  will  appear  later  in  this 
thesis.  The  control  hits  indicate  that  the  urgent  or 
acknowledgement  fields  are  significant,  that  lata  is  to  be 
pushed,  to  reset  the  connection,  synchronize  sequence 
numbers,  and  that  no  more  data  is  to  be  sent  over  this 
particular  connection. 

The  window  field  is  the  number  of  bytes  of  data  that  the 
sender  of  the  segment  is  willing  to  accept  from  the  other 
end  of  the  connection.  This  is  based  on  the  size  of  the 
buffers  available  in  a  particular  implementation  and  how 
much  data  is  in  each  of  the  buffers  at  any  giver,  time.  The 
observed  values  in  the  remote  login  were  predominantly  08  P£ 
hexadecimal,  2Z48  decimal.  The  window  is  the  mehanism  by 
which  a  fast  sender  does  not  swamp  a  slow  receiver.  If  a 
sender  sends  data  that  is  more  than  can  be  received,  that 
data  would  be  discarded,  thus  adding  to  the  network  traffic 
by  necessitating  retransmission.  By  examining  the  sequence 
number   and   window  size  on  an  incoming  packet,   a   TCP   can 


55 


determine  whether  or  not  the  number  of  bytes  that  it  has   to 
send  can  he  received  at  the  otrer  end. 

The  checksum  field  uses  the  same  algorithm  for 
computation  as  the  IP  checksum;  it  covers  a  psuedo  header, 
the  TCP  header,  and  the  data  portion  of  the  segment.  The 
pseudo  header  is  a  12  byte  header  which  contains  the  source 
and  destination  addresses  from  the  IP  header,  a  zero  byte, 
the  protocol  numher'06,  which  indicates  TCP),  and  the  TCP 
length.  The  length  is  the  length  of  the  TCP  header  and 
data;  it  does  not  count  the  12  bytes  of  pseudo  header. 
Should  the  length  be  an  odd  number,  then  a  zero  byte  is 
appended  as  padding  in  order  to  form  the  full  16  bit  words 
for  the  checksum  algorithm.  Figure  4.3  shows  the  format  of 
the  pseudo  header. 


INTERNET  PROTOCOL  SOURCE  ADDRESS 

INTERNET  PROTOCOL  DESTINATION  ADDRESS 

NULL 

PROTOCOL 

TCP  SEGMENT  LENGTH 

Figure  4.3 


Pseudo  Eeader  Format 


The  urgent  pointer  field  allows  the  sender  to  notify  the 
receiver  that  some  urgent  data  follows.  The  pointer  is  an 
offset  value  from  the  sequence  number  of  the  packet  with  the 
urgent  control  bit  set;  it  points  to  the  last  byte  of  urgent 
data.    In  the  remote  losin  process,   the  options  fields   in 
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the  TC?  header  are  utilized  only  during  the  establishment  of 
a  TCP  connection.  The  option  observed  specified  the  maximum 
segment  size  as  being  1224  bytes.  The  padding  field  is  used 
only  to  ensure  that  the  TC?  header  contains  full  32  bit 
words.  The  padding  is  the  zero  byte. 
3.    TCP  States 

A  connection  moves  through  a  progression  of  states 
during  its  existence.  Figure  4.4  is  a  finite  state  model  of 
the  TCP  connection  states.  It  should  not  be  considered  as  a 
complete  state  diagram;  it  depicts  only  a  few  of  the  events 
that  can  cause  a  state  change.  The  TC?  may  change  states 
based  on  the  events  OPEN,  CLOSE,  SEND,  RECEIVE,  and  A.BOET 
and  the  control  flags  that  are  set  in  incoming  segments. 
The  listen  state  represents  waiting  for  a  connection  request 
from  any  remote  TC?  and  pert.  Syn-sent  represents  waiting 
for  a  matching  connection  request  in  response  to  the 
original  connection  request.  The  S£n-receiy_e_d  represents 
the  waiting  for  an  acknowledgement  of  the  syn  which  was  sent 
in  response  to  an  incoming  syn.  The  established  state 
represents  an  open  connection  over  which  data  can  now  be 
sent  in  either  direction.  The  fin-wait-1  state  represents 
waiting  for  a  termination  request  or  the  acknowledgement  on 
one  that  was  sent.  The  fin-wait-2  state  represents  only  the 
waiting  for  a  termination  request.  The  close-wait  state 
represents  waiting  for  a  termination  request  from  the  local 
riser.    The   closing   state   represents  the   waiting   for   a 


57 


closed 


OPEN 


CLOSE 


sy 


n  rcvd  s~ 


¥_ L_ 

listen 

I — _ 

i  i 
i  i 
i  • 
i  ' 
i     ' 

snd  SYN.ACK    !         snd  SYN 


rev  5YN 


SENO 


rev  SYN    snd  ACK 


rev  ACK  of  SYN 


rev  SYN, ACK 
snd  ACK 


syn  sent 


CLOSE 

snd   FIN 

\/ 

fin 

■»alt-l 

_*L 


estab 


CLOSE     i 
i 
< sod.  IJh ! 


rev  FIN  snd  ACK 


rev  ACK  Of  FIN 


rev  F  IN   snd  ACK 


c  lose 
wait 


CLOSE 
snd  FIN 


f f nwal t? 


c losing 


^L 


last  ar^- 


rev  ACK  of  F  IN 


rec  ACK  of  r  IN, 


rev  F IN  snd  ACK 


t Imeout 


i 

i 

i 

V 


>[ 


t I  me  wa I t 


X.  r.lnspf! 


F Iqure  4 .4 


TCP  Stale  ClaqraT 


58 


connection  termination  reauest  acknowledgement  for  the 
remote  TCP.  The  last-ack  state  represens  the  wait  for  an 
acknowledgement  of  the  connection  termination  request 
previously  sent  to  the  remote  TCP.  The  time-wait  state 
represents  waiting  for  enough  time  to  pass  to  make  sure 
that  the  remote  TCP  has  received  acknowledgement  of  its 
connection  termination  reauest. 

When  a  particular  event -takes  place,  the  TC?  response  to 
that  event  depends  upon  the  state  of  the  TCP?  the  same  event 
can  cause  different  TC?  reactions.  The  response  to  inbound 
packets  is  very  complex;  the  algorithms  covering  the  proper 
responses  are  found  in  Reference  3.  The  states  of  the  TCP 
could  he  lumped  together  into  three  primary  states;  the 
first  state  has  to  do  with  getting  a  connection  set  up  from 
one  host/port  to  another,  the  second  concerns  the  handling 
of  inbound/outbound  packets  once  established,  and  the  third 
has  to  do  with  terminating  the  connection.  The  UNIX  command 
NETSTAT  will  show,  among  other  things,  the  state  of  each  TC? 
connect  ion . 

4*    Connection  Establishment 

For  a  connection  to  move  to  the  established  state, 
the  two  TCP's  must  synchronize  on  each  other's  initial 
seauence  numbers.  Since  the  initial  sequence  number  from 
each  socket  is  unique  (they  are  clock  generated,  but  not 
from  a  network  wide  clock),  this  synchronization  is 
necessary  so  that  the  acknowledgement  mechanism  can  function 
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properly.  This  synchronization  is  signaled  by  the  sjrn's 
control  hit  in  the  TCP  header  "being  set.  The 
synchronization  requires  each  TCP  to  send  its  own  uniquely 
determined  seauence  number  and  to  receive  acknowledgement 
that  it  has  been  received  by  the  other  end  of  the  proposed 
connection.  An  example  of  the  connection  establishment  is 
shown  in  Figure  4.5.  The  initial  TCP  from  3  can  contain 
both  the  acknowledgement  and  the  initial  sequence  number 
thus  resulting  in  a  total  of  three  packets.  This  is  where 
the  exchange  get  its  name  of  the  "three  way  handshake'. 

The  demonstration  program  in  this  thesis  does  follow  the 
above  synchronization  of  sequence  numbers  and  produces  a 
connection  that  moves  into  the  "established"  state.   It  does 


a . 

b. 
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A  < B 


c.   A N'  B 


Figure  4.5 


syn,  my  sequence  number  is   X 

ack,  your  sequence  is  X 

syn,  my  sequence  number  is  ? 

ack,  your  sequence  number  is  Y 

TCP  Connection  Establishment 


not  handle,  in  a  TCP  sense,  the  production  of  transmission 
packets  nor  the  processing  of  inbound  packets  in  the 
established  state  nor  for  connection  termination.  The 
algorithms  for  all  event  processing  are  contained  in 
Reference  3  . 
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D.   UNIX  PROTOCOLS 

1 •    background 

All  of  the  protocols  discussed  thus  far  have  been 
very  general  and  can  be  applied  to  many  networking 
situations.  The  Ethernet,  IP,  and  TCP  protocols  do  not 
pertain  directly  to  the  remote  login/terminal  process  per 
se.  They  are  just  as  valid  for  sending  mail,  transferring 
files,  etc.  as  they  are  for  the  remote  login/terminal.  The 
UNIX  protocols  that  will  now  be  discussed  are  specific  to 
the  remote  login/terminal  process. 

2«    UNIX  Remote  Login  Protocol 

A  description  of  the  remote  login  protocols  can  be 
found  in  the  System  Maintenance  section  of  Reference  4.  The 
servers  for  the  protocols  are  F.L0GIND(8C)  and  RSED(SC). 
When  the  UNIX  receives  a  request  for  a  remote  login  over  a 
network,  it  is  RLOGIND  that  is  listenirg  at  the  rlogin  port 
for  such  requests  (listen,  in  the  sense  of  a  TCP  state 
diagram).  Upon  receiving  a  request,  RLOGIND  along  with 
PSHD  checks  to  see  if  the  requester's  source  port  is  witnin 
the  range  1-1023.  They  read  characters  from  the  socket  up 
to  the  null  byte  (00  hexadecimal)  and  interpret  them  as 
ASCII  characters.  They  check  to  ensure  that  the  requestor's 
address  is  one  contained  in  their  host's  name  data  base.  A 
null  terminated  user  name  of  at  most  16  characters  is  next 
read  and  is  considered  to  be  the  user  name  for  the  host 
machine?   a   second  null  terminated  user  name  is  read  and  is 
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considered  the  user  name  on  the  reauestor's  machine.  Next, 
a  null  terminated  command  to  the  UNIX  command,  shell  is 
retrieved.  The  user  name  is  then  checked  against  the  list 
of  authorized  users.  When  all  the  above  steps  are 
successful,  the  null  "byte  is  returned  over  the  connection  to 
the  requestor.  The  connection  is  now  passed  on  to  the 
regular  login  process  for  the  verification  of  the  password. 

The  above  steps  are  those  described  in  the  UNIX 
operating  system  manuals.  Observations  of  the  conversation 
over  the  Ethernet  during  the  remote  login  process  reveal  the 
following.  A  three  way  handshake,  according  to  TCP, 
etablishes  a  connection  from  the  Sun  Workstation  to  the 
remote  login  port  of  the  VAX  system.  (A  UNIX  NETSTAT 
command  issued  after  only  the  three  way  handshake  packets 
have  been  transmitted  will  show  that  the  login  port  of  the 
VAX  has  a  network  connection  to  the  foreign  address,  Sunl. 
The  state  of  the  connection  will  read  'established'.)  In 
the  next  packet,  the  Sun  Workstation  then  pushes  the  null 
byte.*  then  a  new  packet  which  has  the  user  name  as  data, 
then  the  next  packet  which  also  has  the  user  name  as  data, 
then  the  terminal  type/baud  rate  appears  as  data  to  the  VAX. 
The  Vax  will  then  send  "Password"  to  the  Sun  Workstation  as 
data  to  be  displayed  on  the  Sun  terminal.  This  is  the  first 
displayable  data  that  is  passed  to  the  Sun  Workstation.  The 
Sun  will  now  be  using  the  protocol  discussed  below. 
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3.    UNIX  Terminal  Protocol 

Terminals  connected  to  a  VAX  11/780  running  4.2  BSD 
UNIX  are  full  duplex,  character  at  a  time  connections  that 
normally  terminate  at  a  communications  interface  processor. 
When  typing  at  the  terminal,  each  key  stroke  is  sent 
separately  to  the  UNIX?  it  is  returned  or  "echoed"  to  the 
terminal  so  that  it  can  he  displayed  on  the  screen.  The  echo 
is  displayed,  not  the  key  when  struck.  It  is  this  echo 
feature  that  enables  the  user  to  type  in  a  password  without 
it  appearing  on  the  screen.  The  operating  system  knows  when 
the  user  is  sending  a  password,  so  it  does  not  return  or 
echo  the  keystroke  to  the  terminal.  When  using  the  remote 
ter-ninal  feature  of  the  UNIX,  the  remote  terminal  is  treated 
in  the  same  manner  as  described  above.  The  remote  terminal 
process  transmits  each  keystroke  as  a  single  packet;  the 
provider  of  the  service  replies  with  a  single  packet  that 
echoes  the  keystroke  (this  echo  is  then  acknowledged  in  an 
ack  only  segment).  When  the  VAX  system  is  sending  lines  of 
text  to  be  displayed  on  the  remote  terminal,  it  will  send  at 
most  one  line  of  data  in  each  packet  with  ASCII  carriage 
return  and  line  feed  characters  as  the  line  terminators. 

*•    Trailer  Protocols 

Section  70  of  Reference  4  contains  information  on 
the  use  of  trailing  protocols.  They  appeared  after  the  data 
bytes  of  the  TCP  when  the  length  of  IP,  TCP,  and  data  was 
less   than   the   minimum  Ethernet  data  length   of   46.    For 
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instance,  if  the  remote  login/terminal  ARPANET  packet  was 
only  40  bytes  long,  there  was  a  6  tyte  trailer  added  to  the 
packet  to  make  it  a  total  of  46  "bytes  long.  No 
investigation  into  the  contents  of  these  protocols  was 
conducted . 

5.    Summary,  of  Remote  Login/Terminal 

Figure  4.6  depicts  the  protocols  that  have  "been 
investigated  during  the  course  of  this  thesis.  There  would 
he  other  layers  atove  these,  hut  they  were  neither 
investigated  nor   programmed  in  the  demonstration  program. 


UNIX 
LOGIN 


UNIX 

TERMINAL 


UNIX 
TRAILER 


TRANSMISSION  CONTROL  PROTOCOL 


INTERNET  PROTOCOL 


ETHERNET 


Figure  4.6 


UNIX  Remote  Login  Protocols 
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V.   TEST  OF  VIAEI1ITY 

A.   DEMONSTRATION  PROGRAM 

1  •   5P.§Is  of  the  Demons  t  rat  ion  Program 

In  order  to  test  the  viability  of  a  remote  login  to 
the  UNIX  over  an  Ethernet  from  a  CPM  based  process,  a 
demonstration  program  was'  devised  that  mimicked  the  remote 
login  conversations  between  the  Sun  Workstation  and  the  VAX 
UNIX  system.  The  demonstration  program  used  the  Sun 
Workstation's  Ethernet,  ARPANET,  and  login  port  addresses. 
The  program  did  not  attempt  a  full  implementation  of  the 
IP/TCP  protocols  nor  of  the  UNIX  remote  login/terminal 
protocols.   The  goal  of  the  program  was  to: 

a.  establish  a  TCP  connection  between  the  CPM  based 
process  and  the  login  port  of  the  VAX  UNIX  machine 
(three  way  handshake)  and 

b.  to  proceed  through  the  UNIX  remote  login  protocols 
far  enough  that  itthe  VAX  UNIX  transmitted  the 
request  "Password"  (requestor  has  successfully 
passed  through  the  remote  login  and  has  been  handed 
off  to  the  standard  UNIX  login  process). 

The    successful   accomplishment   of   this  could    be 

determined   through  the  use  of  the  UNIX  command  NETSTAT   and 

the   examination   of  the  packets  that  were  sent  by   the   VAX 

system   in  reply  to  the  demonstration  program.  If  the   Sun 

Workstation  is  turned  off  and  then  the  demonstration  program 

is  run,  executing  the  command  NETSTAT  will  show  that  the  VAX 

UNIX  has  a  TCP  connection  "established"  to  its  login   port 

from   the   remote   host  Sunl .    Examination  of  the   packets 

65 


returned  to  the  demonstration  program  by  the  VAX  UNI2  system 
shows  acknowledgement  by  the  VAX  system  of  all  data  received 
and  the  word  "Password"  passed  as  the  data  portion  of  its 
packets.  The  demonstration  program  went  no  further;  the 
user's  password  was  not  sent  to  the  VAX,  no  remote  terminal 
protocols  nor  TCP  connection  termination  protocols  were 
attempted.  Since,  full  protocols  were  not  programmed,  the 
program  assumes  that  a  normal,  trouble  free  remote 
login/terminal  sequence  will  occur.  Thus  there  can  not  be 
any  other  packets  on  the  Ethernet  not  concerned  with  the 
remote  login  process. 

Numerous  observations  of  the  remote  login  were  obtained 
by  the  program  LISTEN.  The  three  way  handshake  was  observed 
as  described  in  the  previous  chapter.  The  demonstration 
program  sent  out  a  request  for  a  connection  to  the  VAX  UNIX 
login  port,  waited  for  the  return  "syn,ack"  from  the  VAX, 
then  sent  an  acknowledgement  of  that  packet.  When  forming 
this  acknowledgement  packet,  the  demonstration  program, 
DEMO,  only  processed  the  inbound  packet  for  its  sequence 
number . 

Figure  5.1  illustrates  the  observed  sequence  for  the 
UNIX  remote  login  protocol.  DEMC  sent  out  its  packets 
assuming  this  would  be  the  sequence  of  events;  it  pushed  the 
four  packets,  waited  for  the  ack  and  then  null  byte  from  the 
VAX,  and  then  processed  the  VAX  packet  for  its  seauence 
number  with  which  it  could  form  an  acknowledgement  packet. 
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2.    Demons t  rat  ion.  Program  Results 

The  demonstration  program  was  successful  in  meeting 
its   goals.    A  TC?  connection  was  estatlished  and  the   UNIX 
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Figure  5.1    UNIX  Remote  Login  Sequence 
remote  login  protocols  were  successfully  negotiated  and   the 
request   passed   onto   the  normal  login  process  of   the   7*X 
UNIX?  the  reauestor  was  asked  for  his  password. 

3»    Significant  Program  Development  Anomalies 

During  the  development  of  both  the  demonstration 
program  and  the  LISTEN  program,  several  important  anomalies 
developed;  one  concerned  the  network  protocols,  another  the 
the  NI3010  board,  and  lastly  the  asynchronous  interrupts 
while  CPM  is  executing  i/o. 

When  DEMO  is  being  used,  it  initiates  a  TCP  connection 
with  the  VAX  UNIX  system  in  accordance  with  the 
specifications.  However,  it  does  not  terminate  the 
connection  according  to  the  TCP  protocol.  when  DEMO  is 
finished,  the  connection  is  one  sided;  the  VAX  still  thinks 
that  it  has  a  connection  to  the  Sun.  The  connection 
eventually  times  out  when  the  VAX  fails  to  receive  any   more 
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packets  on  that  connection.  The  next  time  the  Sun  attempts 
a  remote  login,  the  VAX  system  replies  to  the  initial 
reauest  not  with  an  "ack.syn'  packet  hut  with  a  broadcast 
packet.  The  protocol  for  this  was  not  investigated,  hut  a 
cursory  examination  revealed  that  the  intent  of  the  packet 
appeared  to  he  an  update  to  VAX  UNIX  system  address  tables 
that  were  altered  when  the  previous  connection  from  the  same 
source  terminated  abnormally.  For  further  program 
development,  this  can  he  avoided  by  merely  logging  back  into 
the  VAX  from  the  Sun  before  attempting  the  next  running  of 
DEMO. 

When  running  either  LISTEN  or  DEMO,  the  program  can  run 
to  normal  termination  or  be  terminated  early  if  hung  up  or 
the  desired  number  of  packets  has  not  been  received.  On 
the  AEGIS  multiuser  system,  this  can  be  accomplished  by 
either  resetting  the  MULTIBUS  cluster  or  resetting  only  the 
£6/12  SEC  in  use.  If  either  program  has  been  terminated 
early  by  resetting  the  66/12  SBC,  then  the  next  time  either 
one  is  run  an  extra  byte  of  data  is  transferred  from  the 
board  into  the  extended  TP£.  When  the  receive  data  block  is 
overlaid  on  this  portion  of  memory,  it  is  off  by  this  one 
byte,  thus  causing  the  program  to  improperly  determine  the 
size  of  the  received  packet.  This  can  be  avoided  by  always 
resetting  the  MULTIBUS  cluster  before  running  the  program. 
This  has  the  same  effect  as  turning  off  the  power  to  the 
board   and   then   turning   it   back   on.    This   power   down 
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operation  will  wipe  out  all  buffers  and  registers  on  the 
NI3010  beard.  Both  LISTEN  and  DEMO  will  issue  a  warning 
message  when  there  is  a  size  error  and  then  terminate. 

P1/I-S6  input/output  routines  are  not  re-entrant. 
Therefore,  when  doing  any  i/o,  it  is  necessary  to  do  so  in 
the  NI3010  board  interrupt  handler  or  make  calls  through 
this  handler.  Since  the  first  steu  of  the  board  interrupt 
handler  is  to  disable  the  board  interrupts,  all  code  will 
execute  to  completion  without  interruption;  therefore,  no 
i/o  routines  will  be  interrupted.  If  they  were, 
unpredictable  results  on  the  terminal  will  occur. 
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VI.   CONCLUSIONS 

The  goals  of  the  thesis  were  net  by  the  demonstration 
program's  showing  the  viability  of  a  microcomputer  "based 
process  lodging  into  a  VAX  UNIX  system  over  the  Ethernet. 
The  "basic  information  on  the  protocols  used  is  available? 
they  can  be  implemented  on  a  16  bit  microprocessor;  PL/I  is 
sufficiently  flexible  to  allow  the  linking  of  the  assembly 
language  routines  necessary  to  write  the  device  driver  for 
the  MI3010  board  and  to  perform  32  bit  arithmetic  and  16  bit 
checksums . 

Now  that  the  fundamental  concepts  have  been  recorded,  it 
is  necessary  to  implement,  in  a  modular,  layered  approach 
the  full  remote  login/terminal  caoabili ties .  Once 
accomplished,  it  would  be  possible  to  use  the  prosram  for 
communication  over  the  ARPANET.  By  logging  into  the  Vax 
UNIX  system,  its  full  networking  capabilities  can  be 
utili  zed . 


70 


APPENDIX  A 

PROGRAMMING  NOTES 

There  are  several  features  of  PL/I-86  and  LINK-86  that 
are  important  to  understand  so  that  the  programs  and  linking 
insructions  for  them  can  he  understood. 

The   linking  command,  for  both  LISTEN  and  DEMO  are   quite 

similar?  the  only  real  differences  are  the  assembly  language 

modules   that   are   linked  into  each.    The   main   point   to 

understand  about  them  is  the  parameter  listing  for  the  PI/I- 

36   program.    The   linking   commands   used   were:   "link86 

listen[i]"   and  "link86  demo[i]"  where  the  "[i]"  option   was 

an  input  file  for  the  linker.   The  input  file  was: 

demo    [data  [abs  [300]  ,m  [0]  ,ad  [82]  ,map  [all]]  , 
cksum,    add32bit ,xternasy 

The   first  parameter  for  DEMO  says  to  load  the  data   segment 

register   of   the  8086  microprocessor  with  3C0   hexadecimal. 

This   forces  the  data  segment  of  64K  bytes  to  run   from   the 

base   address   of  8000  hexadecimal   to  17fff  (remember   that 

address   registers  are  left  shifted  by  four  bits  before   the 

offset   is   added)  .   Thus  one  half  the  data  segment   is   on 

36/12   S5C   onboard  memory  and  the  other  half   of   the   data 

segment  is  located  in  the  extended  TPA.   The  reason  for  this 

straddle   of   onboard/extended   memory  is  that   the   onboard 

memory  is  strapped  so  that  it  is  unaccessible  from  MULTIBUS. 

Since   the   NI3010  needs  to  transfer   packets   to/from   host 
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memory,  it  must  do  so  to  the  portion  of  the  lata  segment 
which  is  in  the  extended  memory. 

The  "m[0]"  data  parameter  tells  the  linker  to  allocate 
no  additional  memory  for  the  data  section  of  the  command 
file.  This  prevents  the  overwriting  of  command  file  data  "by 
the  transfer  of  packets  into  the  extended  TPA  which  lies 
witnin  the  data  segment  address  space. 

The  "ad[82]"  data  parameter  gives  the  total  number  of 
additional  paragraphs  to  allocate  to  the  data  segment  of  the 
command  file.  This  enables  the  user  to  run  either  LISTEN  or 
DEMO  within  the  local  memory  of  the  iSEC  86/12. 

The  combination  of  the  linker's  loading  of  the  data 
segment  register  with  82*0  hexadecimal,  the  PL/I-86  "unspec" 
built  in  function,  and  the  PL/I-86  pointer  based  structures, 
allows  the  programmer  to  locate  a  template  in  the  extended 
TPA  for  the  transmit  data  blocks  and  receive  data  blocks 
for  the  NI3010  DMA  operations.  Eor  instance,  in  the  LISTEN 
program,  the  linker  has  loaded  the  data  segment  register 
with  830  hexadecimal,  and  the  receive  data  block  is  based  on 
a  pointer  whose  value  is  forced  to  be  8000  hexadecimal  by 
the  PL/I-86  statement  "unspec'x)  =  '8000'b4l"  Thus  the 
address  of  the  receive  data  block  is  the  sum  of  the  8000 
hexadecimal  and  the  800  hexadecimal  (left  shifted);  this 
yields  an  address  of  10000  hexadecimal,  which  is  the  first 
byte  of  the  extended  TPA. 
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An  important  point  to  remember  in  network 
implementations  is  that  only  binary  information  is  received 
or  transmitted.  The  interpretation  of  each  byte  of  binary 
0's  and  l's  is  up  to  the  implementation.  A  byte  could  be 
considered  to  be  a  character,  an  integer,  or  control 
information.  For  this  reason,  all  declarations  of 
structures  which  are  used  as  overlays  for  the  networking 
packets  are  declared  as  "bit(3)"  in  PL/I-36.  The 
interpretation  of  these  as  characters  or  control  is  no  real 
problem.  However,  when  a  particular  byte,  or  more  normally 
a  group  of  two  bytes,  are  to  be  considered  as  integers,  then 
it  was  necessary  to  overlay  the  bit  string  with  a  based 
variable  whose  type  was  declared  as  "fixed",  "fixed  bin(7)'t 
or  "fixed  bin(15)"  in  PL/-36.  This  is  because  run  time 
conversions  of  bit  to  fixed  values  caused  unexpected 
results  . 

Another  important  point  is  the  manner  in  which  PL/I-36 
stores  integers  and  hexadecimal  values.  A  two  byte  integer 
is  stored  with  the  least  significant  byte  preceding  the 
most  significant  byte  in  memory.  Thus  overlaying:  a  "fixed" 
or  "fixed  bin(15)"  over  the  length  bytes  of  the  NI3010 
receive  frame  is  acceptable  because  the  protocol  says  that 
the  least  significant  byte  is  first  in  memory  followed  by 
the  most  significant  byte,  just  as  in  PL/I-36.  This  will 
not  work  for  the  length  bytes  as  they  are  stored  for  the 
Internet   Protocol.    There   the  two  byte  integer   value   is 
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transferred  into/out  of  memory  with  the  most  significant 
byte  first  followed  by  the  least  significant  byte. 
Therefore  a  two  byte  PL/I-S6  variable  cannot  be  overlayed  on 
the  IP  length  bytes.  Similarly,  the  hexadecimal  value  12  34 
is  stored  in  memory  as  34  12.  This  is  important  when 
storing  16  bit  hexadecimal  values  in  bit(16)  variables  such 
as  the  TCP  source  and  destination  Dort  addresses. 
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APPENDIX  "5 

NI3010  DEVICE  DRIVER  ASSEMBLY  LANGUAGE  MODULES 

date:20  November  1984 

author:  David  J  Brewer 

These  3086  Assembly  language  modules  were  developed  by 
Erewer  for  his  thesis.  [Ref.  5]  They  are  linked  into  any 
program  that  needs  to  utilize  an  Interlan  NI3010  Ethernet 
Controller  Board.  They  read/write  to  the  various  ports  of 
the  NI3010,  initialize  the  interrupt  5  for  the  CPU,  and 
enable/disable  the  CPU  interrupts. 


XTERNAST 


extrn  hl_interrupt_handler  :  far 

public  write_io_port 

public  read_io_port 

public  write_bar 

public  init  ialize_cpu_interrupt s 

public  enable_cpu_interrupts 

■public  disable_cpu_interrupt s 

•  ris  sjc  3[t  ^  ^t  ^i  «  ^s  *; «  5jt  rfc  ^t  *t  si;  5*t  ;};  ;  »  ;';  3{s  5*t  i\t «  ^t  is  z£  sfic  «  3m  5jc  it  ;£  jds  ^  «  ^  «  «  ^c  ^  ^  ^  ^  ^  ^;  *t  j'j  ^  ^*  y<  «  ;*  ^c  ^  5^  ^t  ii;  ;!x : 

write_io_port : 

;  Parameter  Passing  Specification: 

entry  exit 

parameter  1     <port  address>  <unchanged> 

parameter  2     <value  to  be  outputted>   <unchanged> 


dseg 

port_address    rb   1 

cseg 
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push    bx  !    push    si!    push    It!    push   ax 
si,    [bx] 


mov 

[71  CV 

mov 
mov 
mov 


al,    [si] 

port_addres s ,    al 

si  ,    2  [bx] 

al,    [si] 
mov      dl,    port_address 
mov      dh,    00h 
out      dx,    al 

pop   ax!    pop   dx !    pop   si!    pop    bx 
ret 

•  ric  &  ?'  ?''  X<  5tc  ris  i;  ±x  xx  ;£ ; lt  fx  xt  —  x^  «  Xc  x~  sis  xx  ri  «  x^  xi  x^  i:  x<  X' X:  «  ^t  ^  ^  ^  Xi  «  ^  ^  «:  i: «  ^  i;  ^  ri;  ii  * :  ^  ii  ^t  ii:  iU  i:  sJt  ii  rit  - 
»,-»  *n  *t*  *»*  *p  t*  *t*  * p  a*  ^r*  hp  ip  hh  ^^  ^^  o*  *i*  a*  *i*  t*  *r  *t*  *t*  *r  **r*  **  *p  *p  *»*  i*  i*  *v*  *»    *i*  *p  *i*  *i~  *t*  *p  a*  h*  *i*  *r*  *s*  *p  t*  *i*  *\    *r*  t*  *^*  i*  *i*  * p  a*  t*  at*  ■ 


read_io_por t : 

Parameter  Passing  Specification 

entry 

parameter  1    <port  address> 
parameter  2    <meaningless> 


exi  t 

<unchanged> 

<register  value> 


cseg 

push   bx!    pushsi!    push   dx!    push   ax 

mov 

mov 

mov 

mov 

mov 


si,       [bx] 

al,       [si] 

port_address ,      al 

si,    2[bx] 

dl,  port_address 


mov  dh,   00h 

in  al ,   dx 

mov  [si] ,  al 

pop  ax!  pop  dx !  pop  si!  pop  bx! 

ret 


.  J-  .1.  J,  »!.  ^,  ...  J,  .v  J,  »l.  ,',  ,'.    ■„  <J-  -  -  -  -  » 


.  -J.  -J*    •,>,     -J* 


:#^*: 


writ  e_bar : 

Parameter  Passing  Specification 

parameter  1  :the  address  of  the  data  block  to  be 
transmitted  or  received. 


dseg 
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e_bar_port 

h_bar_por  t 
l_bar_port 
temp_e_byte 
temp_es 

cseg 


equ 

3b9h 

equ 

0  b  ah 

eau 

2bbh 

rb 

1 

rw 

1 

?  This  nodule  computes  a  24  bit  address  from  a  32  bit 

;  address  -  actually  it's  a  combination  of  the  SS  register 

?  and  the  IP  passed  via  a  parameter  list. 

push  bx  !  push  ax!  push  ci!  push  es!  push  dx !  push  si 


add_l: 
no   add: 


mov 
mov 
mov 
mov 
mov 
mov 
mov 
shr 
mov 
mov 
mov 

shl 
add 

jnc 

inc 

out 
mov 
out 
mov 
out 
pop 
ret 


common   memory   segment 


dx,      0S03h 

es ,      dx 

temp_es ,    es 

dx,      es 

si,      [bx] 

ax,      [si] 

cl,      12 

dx,      cl 

temp_e_byte,        dl 

dx,      temp_es 

cl,      4 

dx ,      cl 
ax ,      dx 

no_add 
temp_e_byte 
l_bar_port ,  al 
al ,  ah 

h_bar_por t  ,    al 
al,    temp_e_byte 
e_bar_por  t ,    al 
si!    pop   dx !    pop   es !    pop    ex!    pop   ax!    pop   bx 


initiali  ze_cpu_interrupt s : 

;  Module  Interface  Specification: 

J     Caller:        Ethert est (PL/I )  Procedure 

;     Parameters:    NONE 
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ir.itmodule  cseg   common 
ors  114:h 

int5_offset        rw    1 
int5   segment      rv    1 


cse^ 

push  bx 

push  ax 

mov   bx ,   offset  interrupt _handler 

mov  ax ,   0 

push  ds 

mov  ds,   ax 

mov   ds :int5_of f set  ,  ox 

mov   ox ,  cs 

mov   ds :int5_segment ,  bx 

poD  ds 

pop  ax 

pop  "bx 

sti 

ret 


enable_cpu_interrupts: 

;  Module  Interface  Specification: 

;      Caller:  Sthertes t ( ?L/I )  Procedure 

J     Parameters:  NONE 


sti 
ret 


disable_cpu_interrupts  : 

;  Module  Interface  Specification: 


;     Caller: 

;     Parameters: 

cli 
ret 


Ethertest(?L/I )  Procedure 
none 
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inter rupt_handler 


IP,  CS,  and  flags  are  already  on  stack 
save  all  other  registers 


push  ax 
push  dx 
push  ex 
push  dx 
push  si 
push  di 
push  bp 
push  ds 
push  es 

call  hl_interrupt_handler 

;  high  level  source  routine 
J  In  Ethertest  Module  (PL/I) 


J  restore  registers 


end 


pop 
pop 
pop 
pop 
pop 
pop 
pop 
pop 
pop 
sti 
iret 


es 

ds 

DP 

di 
si 
dx 
ex 

DX 

ax 


79 


APPENDIX  C 

LISTING  OP  LISTEN  PROGRAM 
listen:  procedure  options  (main); 

/*!!!!!!!!!!!!!!!!!!!!!!! !l !!!!!!! I !!!!!!!!!!!!!!!!!!!!!!! ! 

date:  20  november  1984 


John  Donald  Reeke 
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?  !  ?  I  f  !  »  T  ?  »  ?  I  »  !  t  !  f  M  »  t  J  M  I  ?  t  I  M  T  I  !  I  M  t  »  1  F  !  M  t  1  !  ?  T  !  I  »  I  »  T  !  !  !  *  / 


declare 


rece  ive_data_ 

2  frame_st 

2  null_byt 

2  frame_le 

2  frame_le 

2  destinat 

2  destinat 

2  destinat 

2  destinat 

2  destinat 

2  destinat 

2  source_a 

2  source_a 

2  source_a 

2  source  a 


block  b 

atus 

e 

ngth_ls 

ngth_ms 

ion_add 

ion_add 

ion_add 

ion_add 

ion_add 

ion_add 

ddress_ 

ddress_ 

ddress_ 

ddress 


ased 


b 
b 
ress 

ress 

ress 

ress 

ress' 

ress 

a 

b 

c 

d 


rec_blk  ptr), 
bit  13)  , 


bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 
bit 


(S) 
(8) 
(6) 
(6) 
(8) 
(3) 
(3) 
(3) 
(3) 
(8) 
(8) 
(3) 
(8) 


E0 


2  source_address_e  bit  (8) 

2  source_address_f  bit  (3) 

2  type_field_a  bit  (8) 

2  type_field_b  bit  (8) 

2  data  (1500)  bit (8) , 

2  crc_msb  bit  (8) 

2  crc_upper_middle_byte  bit  (8) 

2  crc_lower_middle_byte  bit  (3) 

2  crc  lsb  bit  (6) 


size_ptr  pointer, 

size   fixed  bin(15)  based  (size_ptr), 

fill_xtpa(15000)  char  based (rec_blk_ptr ) , 

output_type  char(l), 

user_desires  fixed, 

packet  file, 

rec_blk_ptr  pointer, 

number_of _packets  fixed  static  init(3), 

copy_ie_register  bit(8), 

i   fixed  bin  (15), 

reg_value  bit  (8)  , 

border  (80)  char  (1)  static  initial  ((80) 


-'), 


/*   Modules  external  to  this  module  */ 


write_io_port  entry  (bit  JS) 
read_io_port   entry  (bit  '.8) 
initialize_cpu_interrupts 
enable _cpu_ interrupts 
disable_cpu_interrupts 
write_bar  entry  (pointer); 


,bit  (3) 

,bit  (3) 

entry, 

entry , 

entry, 


), 

), 


/' 


end  module  listing   */ 


%replace 


next_page 
clearscreen 


y   i  » 

by    z  ; 


/*   codes  specific  to  the  Intel  8259a 

Programmable  Interrupt  Controller  (PIC) 


/* 
/* 
/* 

/* 

/* 


note  that  */ 
icw2 ,icw4,*/ 
and  ocv  */ 
use  same  */ 
port  addr  */ 


icwl_port_ ad dress 
icw2_port_ ad  dress 
icw4_port_address 
ocw_port_address 


by  'c0'b4, 

by  'c2'b4, 

by  'c2'b4, 

by  'c2'b4, 
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/*  note:  ic 


:N  initialization 
control 
word 


ocw  ==>  operational 
command 
word 


*/ 


cwl 


by  '13'b4, 


/*  single  PIC  configuration,  edge 
triggered  input  */ 


cw2 


by  '4?'b4, 


/*  most  significant  bits  of  vectoring 
byte;  for  an  interrupt  5, 
the  effective  address  will  be 
(icw2  +  interrupt  #)  *  4  which 
will  be  (40  hex  +  5)  *  4  = 

114  hex  */ 


icw4 


by  Of  b4, 


/*  automatic  end  of  interrupt 
and  buffered  mode/master   */ 
ocwl  by  '9f'b4, 

/*  unmask  interrupt  5  fbit  5)  and 
mask  all  others  */ 

/*   end  8259a  codes  */ 


/*  include  constants  specific  to  the  NI3010 
board 


V 


%include  'listen. del ' ;   /*  see  APPENDIX 


n      sf 


/ 
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/«!«  *l*  ,1,  *t*  ^.   ,  '.  *i,  «l«  «u  -J*  -'.  »»-  »<*  -<-  •'*  -'-  ~'-  %«*  -J*  -  <~  «A«  -'-  -<-  >'-  -'-  »'*  »*#  J-  »'-  «A-  «J*  -'-  -'-  U-  .'*  ,',  «l«  x>«  ,*.  «<-  <J«  »•*  «*«  «'.#  %'»  »•*  »t#  »*- 
1*  *p  v  *r  *r  'r  -i-  T~  »r  *i*  *i-  -p  *i*  *r*  -i*  1"  n*  *.*  i-'i*  'i-  *t-  -i*  -i»  *t*  *  -  ^  t  '.-'i*  *\»  i-  ***  n~  *»*  *t~  *i-  "i-  *r»  *r  'i*  1*  *»»  T  *i*  -i*  "i*  n- 


» ^»  *t«  t 


:;:  $  $  ^j  *  / 


/*     Mam  Eody  */ 


/* 


*/ 


disable  the  ni3010  "board  so  that  it  does  not  interrupt 
this  new  initialization 


call  write_io_port(interrupt_er.able_register, 
disable_ni3010_interrupts ) ; 


/* 

*/ 


initialize  ni3010,  PIC,  and  CPU  interrupts 


call  read_io_port  ( commandos tatus_regist er , reg_value ) ' 

call  perf orm_command(go_of fline ) ; 

call  perf orm_command(reset ) ; 

call  initial! ze_pic; 

call  ini tiali ze_cpu_in terrupt s ; 


/* 


*/ 


set  the  receive  block  case  address  at  3000  hex, 
the  first  memory  location  in  the  extended  tpaj 
fill  the  extended  tpa  with  '*' 


unspec ( rec_blk_ptr )  =  '8000'b4J 
do  i  =  1  to  15000; 

fill  xtpa(i)  =  '*'; 

end; 


fi 


*/ 

put 

put 

put 

put 

put 

get 

put 

open 

put 

put 

set 


user  interface 

lis  t  ( clearscreen) ; 
skip; 

edit  ((border  (i)  do  i  =  1  to  80))  (a); 

skip  listCSMTEE  1  FOR  HEX  PRINTOUT  :ENTEF,  2  F07  BINARY'); 
skip; 

list ( output_type) ; 
skip; 
file  (packet)  stream  output; 

skip  list('How  many  packets  do  you  wish  to  receive'); 
skip; 

list(user  desires); 
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/* 

7 


put  ni3010  online  and  prepare  to  receive  packets 


call  pe rf orm_ccmmand (go_online ) ; 
call  perform_command(set_promiscuous_mode); 
copy_ie_re£is ter  =  recei ve_block_a vailable ; 
call  write_io_port  (  in  terrupt_enable_register  , 

receive  "block  available); 


/* 


*/ 


wait   until  user  specified  number  of  have  been   packets 
received 


do  while  ( number_of _nackets  <  user_desires  ); 
end; 


/' 


reset  the  ni3010  to  clear  buffer?  close  file 


*/ 

call  perform_command  (reset); 

put  skip  (3); 

put  edit  ((border  (i)  do  i  =  1  to  30))  (a); 

put  skip  (2) J 

close  f ile ( packet ) ; 

/*  end  main  body  */ 


This  module  initailizes  the  programmable  interrupt 
controller  on  the  86/12  S5C 

3,5  V  ^5,i  V  -i~  V  *r  ^  -r  n*  -i*  -t»  *i* ^»  *?  *fi  *j^  *? 3f!  *,»  -r»  *,*:,%  2,4  ^p  2,'  iy.  5,*  5,*  V^r  «^»  7£  *S  ?fc  *r-  V  *i<n*  *p  *i*  n*  'i*  V  5lc  ->»  V  *i*  ^\-  -r  ^  *»-*>*  *i»  3£  ^r  n"  / 

init ialize_pic :    procedure; 

declare 

write_io_port  entry  (bit  (8)  ,  bit(8))J 
call  wri te_io_port  ( icwl_port_address , i cwl ) ; 
call  wri te_io_port  ( icw2_port_address , icw2 } ; 
call  wri te_io_por t  ( icw4_port _addres s , icw4 ) » 
call  wri te_io_port  ( ocw_port_addres s , ocwl ) ; 

end  ini tialize_pic; 
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T  ,,,  -t.*r  . 


This  -nodule  sends  to  the  NI3010  "board  the  command  received 
in  the  parameter  list.  It  then  waits  to  see  if  the  command 
has  "been  successfully  carried  out  by  the  hoard. 

JU^ft  *U  -Jr  -J-  -^  «X-  -'-  -1-  «a-  *'**JU»A*  -J-  i--  o-  -j-  .l.  ^-  *j-  »'>*'*  +**•>*+  «U^«i«^  JU«i^  «V  *'-  i'"  "'*  »'-  -1-  -'-  -1-  •'*-''  *l#  -J*  »J*»I*  *U  J*  *U  •'■  *JU  ->-  -'-  -'-  —  -J-  -r,  -»-  .'-  _'.  .',  , 
T  -T-  -r-  T"  T*  nr  *1%  "V  *T*  *i"  l*  V*f»  TTT;rTTTT*)*T,TTTO"VT'i'"i>  *i*  Jt>  *.»  *l*  T  *l*  *¥■  'l**i**  »i»  -T"  *i*T*  "i*  **T  "I*  •»■  "I*  *»*  I"***  "i»  *">*  *|-  -V*  »i-  1*  I-  / 

perf orm_command :        procedure  (command); 

declare 

command  hit  (8)  , 

reg_value  hit  (S)  , 

srf  hit  (8)  . 

write_io_port  entry  (hit  (8)  ,bit  (8)  ), 

read_io_port      entry    (hit    (3)    ,hit    (3)    )J 


srf  =  '0'b4J 

call  write  io_port  (command  register  .command ) > 

do  while  (Tsrf  &  '01 'M)  =  700't4); 

call  read_io_port  (interrupt_status_reg, 

srf) ; 
end;   /*  do  while  */ 
call  read_io_port  (command_status_register , 

reg_value ) ; 
if  (reg  value  >  '01  '"b4)  then 
do; 

/*  not  (SUCCESS  or  SUCCESS  with  Retries)  */ 

put  skip  edit  ( '***  ETHERNET  Board  Failure  ***') 
(col(35) ,a); 

stop; 

end; 
end  perf orm_command ; 


/v),  *l-  s»*  vU  V-  O* 
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odule   is  called  by  the  assembly   language   interrupt 

It  handles   three  NI3010  interrupts:   the  receive 

vailable,  receive  dma  done,  and  the  transmit  d^a  done 

pts.    It   also   checks  for  the  ^13010  anomaly   and 

out   an   error  message  and   terminates   the   program 

the   anomaly  exist.    The   receive   block    is 

ioned   in  memory  after  each  packet  has  been  dma'ed  to 
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Xt^n*/ 


HL_interrupt_handler:     procedure  external; 

declare 

vri te_ic_?ort  entry  (bit  (8)  ,bit  (S)  ), 
read_io_?ort  entry  (bit  (8)  ,bit  (3)  ), 
enable_cpu_interrupts         entry, 
disable_cpu_ interrupts        entry, 
write  bar  entry  (pointer); 


/* 


don't  let  anything  interrupt 


call  disable_cpu_int errupts ; 

call  write_io_port( interrupt_enable_register, 

disable_ni3  010_ interrupts); 


if  ( copy_ie_regis ter  =  receive_block_available)  then 
do ; 

call  write_bar  (  addr  (  receive_data_bl  ock  )  )  ; 
call  wri te_io_port  high_by te_coun t_reg , '06 'b4 ) ; 
call  write_i  o_port (low_byte_count_reg,'00'b4); 

/*  initiate  receive  DMA  */ 

copy_ie_regist er  =  receive_dma_done » 
call  write_io_port'interrupt_enable_register, 

receive  dma  done ) J 


end; 


/*  if  receive  block  available   */ 
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else 

if  (  c  opy_ie_regi  s  ter  =  recei ve_dma_done )  then 
do? 

number_cf_packets=number_of _packets  +  15 
size_ptr= 

addr(receive_data_block.f rame_length_lsb)  ; 
/*   check   for   ni30ie   anomally   and,    if 
present   set  number  of  packets  so   that 
we   drop   through   to  the   end   of   the 
program   */ 
if  (size  >  1522  !  size  <  64)  then 
do? 

put  skip  listCSIZE  ERROR'); 
number_of _packet s  =  user  desires; 
end; 
else 

call  print_packet ; 

/*  below  repositions  the  receive  data 
block  overlay  */ 
rec_blk_ptr  = 

addr( receive_data_block .data ( si ze  -  4)); 
If  (number_of _packets  )=  user_desires )  then 

call  write_io_port(interrupt_enahle_reffister, 

disahle_ni3010_interrupts ) ; 
else 
do; 

copy_ie_regi s ter  =  receive_block_available; 
call  write_io_pcrt/vinterrupt_enable_  re  lister, 

receive_block_available); 
end; 

end;   /*  if  receive  dma  done  */ 

else 

if  (copy_ie_register  -  transmi t_dma_done ) 
then  do; 

copy_ie_regi  ster  =  receive_block:_available  ; 
call  write_io_port'interrupt_enable_re«?ister  , 

receive_block_available) ; 

end;   /*  if  transmit  dma  done  */ 
end  HL_interrupt_handler ; 
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/~u»  y«  J*  -k.  %.<,  vi-  -i-  o-  -i»  *j«  -  -  --  •.'*+/*  •,'■'  «*-  ""  *'"  — -  «•'*  —  -1*  V*  ■*'-  -  -  -—  -'-  >'••  •.'"  *'*  -'•  -'■-  w^  -<*  *'y  «f«  *■>  *»*  -■'■>  O0   ^)'  v^  «l>  «V  *"  -<-  *'*  —  «"  -'*  "'•»  —■»  *'-  *'*  *'*  -:-  -1-  *'»  ■»"* 
*P  *t*  *|*  »p  T  *V  T*  "Ht*  ^T  T  T*  T*  *1*  *T-  *\*  1"*  T"  T  *»*  «V  T*  I*  •T"  T*  ^T*  T  T*  -n*  1*  ***  T*  "T*  T  1*  T*  *T*  *T  1*  1*  «T*  •">*  *|*  1*  T*  T*  *T*  -f*  "l-   *T~  1"  f»  «T»  *i»  n*  T*  *V  T>  *P  *|* 

This   module  is  called  from  the  HL   interrupt   routine.  It 

prints   each  packet  received  into  the  file  PACOT.DAT.  Its 

output   is  either  in  hexadecimal  or  binary,   as  selected  by 
the  user . 
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print_packet : 


procedure; 


/- 


*/ 


print  out  destination , source , frame  status,  frame 
length,  and  frame  type. 


if  ( receive_data_block .des tinati or_adiress_f  =  '27'b4) 
then  out  file(packet)  skip  list 

'  (  '  from  VAT  to  SUM' ); 

else  if  ( receive_data_block.destinat ion_address  f  = 

'7f"b4) 
then  put  file(oacket)  skip  list 

('  from  SUN  to  VAX'); 

else    put  file(packet)  skip  list ( 'BHOADC AST  PACKET'); 

put  file(packet)  skip? 

put  file(packet)  edit(  'frame  status  = 

receive_data_block.frame_status) ' skip, a , b( 5} ) ; 
put  file(packet)  skip  list 

('frame  length  =        ',size)J 

put  file(packet)  edi t (  'type_f ield_a  = 

receive _d ata_b lock. type_field_a)( skip, a, b(S)}; 

put  file(packet)  edi t ( 'type_f ield_b  = 

receive _data_b lock. type _field_b)( skip, a,b(3i); 


*/ 


this  section  prints  out  the  I?  and  TCP  headers 
in  either  hex  or  binary 


put  file(packet)  edit('the  data  is  :  ' )  { skip  ,a ) ; 
put  file(racket)  skip; 
do  i  =  1  to  20; 

put  file(packet)  skip; 

/*  is  user  selected  hexadecimal  output  */ 
if  ( output _type  =  'l')  then 

put  file ''packet )  eiit('data  ',i,'=  ', 
receive_data_block .data ( i ) , 'da ta  ',(i  +  20),'= 
recei ve_data_block .data ( i  +  20)) 
(a,f(4)  ,a.b4(2),col(30) ,a,f (4) ,a,b4(2) ); 
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else 

put  file 'packet )  edit ('data  ',i,'=  ', 
receive_data_block  .data  (  i  )  ,  'da  ta  ',(i  +  22),'- 
receive_data_block .data ( i  +  20)) 
(a,f (4),a,b(8) , col (30), a, f (4),a,b(6)); 

end; 

put  file ( packet )  skip; 


/* 


*/ 


prints  out  data  portion  of  TC?  in  either  hex 
or  binary 


do  i   =41  to  (size  -  18) ; 
put  file(packet)  skip; 

/*  if  user  has  selected  hexadecimal  output  */ 
if  (output_type  =  'l')  then 

put  file(packet)  edit('data  ',i, '=  ', 

receive_data_block.data(i ) ) (a ,f (4) ,a,b4{2) ) ; 
else 

put  file(packet)  edit('data  ',i,'=  ', 

receive_data_block.data(i))(a,f(4),a,b(8)); 
end  5 

put  f ilefnacket )  skip  list  (next_pa^e); 


end;    /*  print_packet  */ 


end;  /*  procedure  listen  */ 
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APPENDIX  D 

LISTING  OF  DEMONSTRATION  PROGRAM 
demo:    procedure  options  'main); 
/* I ! I !!!!!!!!!!! 1 1 !!!!!!! I !!!!!!!!! I ! 1 !!!!!!!!!!!!!!!!!!!!!  ! 

date:  20  November  1984 


author:  John  Donald  Reeke 


This 

the 

Ethe 

desi 

the 

sour 

only 

for 

Inbo 

seau 

It 
many 
Sine 
incl 
shou 
dest 
plac 
the 
debu 

Be 
Sun 
pack 
util 
turn 
Ethe 


prog 

AEGIS 
rne  t 
gned  t 

VAX 
ce  add 
go  a 

the 
und   o 
ence  n 

initi 
pack: 
e  thi 
uding 
Id  be 
ina tio 
ed  con 

termi 
gging 
f  o  r  e  e 

have 
ets  , 
ized 
ed   of 
met . 


ram  d 
mul 
to  t 
o  mim 
and 
ress  , 
s  far 
VAX  t 
acket 
umber 
alize 
ets  t 
s   pr 

its 
sel 
n   of 
secut 
nal . 
tool 
x  e  c  u  t 

logg 
as  di 
in  th 
f   so 


emonst r 
tiuser 
he  VAX 
ic  the 
therefo 

and  so 

in  the 
o  send 
s  from 

and  wh 
s  the  n 
o  captu 
ogram  c 

own  tr 
ected . 

the  re 
ively  i 
It  i 
such  as 
ing  thi 
ed  in  t 
s cussed 
e  login 
that 


ates  that 
system 

11/7S0  ru 

remote  lo 

re  uses  t 

urce  port 

remote  1 

the  data 

the  VAX  a 

ether  or 

13010  boa 

re  before 

aptures  a 

ansmissio 

Next  th 

mote  logi 

n  memory; 

s  necessa 

DDT-S6  t 

s  program 

o  each  ot 

In  the  b 

procedur 

it  does 


a  CPM-86 
can  remot 
nning  4.2 
gin  of  th 
he  Sun's 
The  pr 
ogin  proc 
"Password 
re  proces 
not  they 
rd  and  th 

terminat 
11  packet 
n  s  ,  ami 
e  user  is 
n.         All 

no  c o n  t  e 
ry  to  loo 
o  examine 
,  ensure 
her  to 
ody  of  th 
e .  Also 
not  put  a 


proce 
ely  1 

BSD 
e  Sun 

Ethe 
ogram 
ess  as 

to 
sed  on 
contai 
en  ask 
ion  of 
s  on 
nimum 

prom 
packet 
nts  ar 
k  in  m 
the  p 
that  t 
preclu 
e  thes 
,  the 
ny  pa 


ss  r 

ogin 
UNI 
Work 
met 
is  i 

i  s 
this 

ly 

n  da 

s  th 
the 
the 
of  2 
pted 
s  re 
e  d  i 
emo  r 
acke 
he  V 
de 
is  , 

Sun 
cket 


unning 

over 
X.  It 
statio 

addr 

ntende 

neces 

proc 
for   t 
ta  . 
e  user 

pros 

Ether 

2   pac 

for 
re  ived 
splaye 
y  wit 
ts  . 

AX  and 

broad 

from  b 

mus  t 
s   on 


on 
an 

is 
n  to 
ess  , 
d  tc 
sary 
ess  . 
hei  r 

how 
ram . 
net, 
kets 
the 
are 
d  to 
h      a 

the 

cas  t 

sing 

be 

the 


!!!!!!!!!!!!  S  !!.'!!!!!  I  !!!!!!!!!!!!  !!!!!!!  IN  !!!!!!  I!  !!!  !!* / 

declare 


/*   The   source  address  is  included  in  the   transmit 
data  block  because  the  ni3010  is  more  efficient 
with   the   automatic   insertion   of   the   source 
suppressed  by  the  "clear  insert  source  address" 
command  */ 

transmi t_data_bl ock  based  ( trans_blk_ptr ) , 

2  des tination_address_a   bit  (8), 

2  des tination_aidress_b    bit  (8), 

2  destination  address  c   bit  (3). 
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destination   address   d        bit    (8), 


2 

2  des t inat i cn_address_e  bit 
2  des t ination_aidress_f  bit 
2  s ource_address_a  bit  '8), 
2  s 3urce_address_b  bit '3) 
2  s ource_address_c  bit'8) 
2  source_address_d  bit'8) 
2  source_address_e  bit(8) 
2  source_address_f  bit'8) 
2   type_field_a  biU8) 

2   type_field_b  bitf'8) 

2  data    (100)  bit(8) 


\  3  ; 


rece 
2  f 
2 
2 
2 
2 
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ress 
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sb 
sb 

dress_a 
dress_b 
dres  s_c 
dress_d 
dress_e 
dress_f 
_a 
_b 
_c 
_d 
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le_byte 
le_byte 


rec_blk  ptr ) , 

bit  (37, 

bit  (8) 

bit  (8) 

bit  (8) 

bit  ( 8 ) 

bit  ( 8 ) 

bit  (3) 

tit  ( 8 ) 

bit  (8) 

bit  (3) 

bit  (8) 

bit  (8) 

bit  (8) 

bit  (8) 

bit  (3) 

bit  (8) 

bit  (8) 

bit  (8) 

bit  (8) 

bit  (8) 

bit  (8) 

bit  (8) 

bit  (3) 


/*  how  many  packets  does  user  want  to  receive  */ 
user_desires  fixed, 

/*  size  of  the  Ethernet  Packet  */ 
size_ptr  pointer, 
size   fixed  bin(15)  based  (size_ptr), 

/*  pointers  to  position  overlays  in  memory  */ 
( trans_blk_ptr ,rec_blk_ptr)  pointer, 

/*  number  of  packets  received  by  this  program  */ 
number_of ^packets  fixed  static  init(0), 

copy_ie_register  bit(8), 
i   fixed  bin  (15) , 
reg  value  bit  (8)  , 
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/* 


Modules  external  to  this  module  */ 


add32bit    entry    (bit(S) , bit (3) ,bit {3 ) ) , 

cksum      entry    (bit(c),  fixed  bin  (7),  bit,  (16) 

wri te_io_port  entry  (tit  '8}  ,bit 

read_io_port   entry  (bit  (8 

initiali  ze_cpu_interrupts 

enable_cpu_interrupts 

disable_cpu_ interrupts 

vrite_bar      entry    (pointer); 


vS  ) 


,  oi  t 
entry , 
entry , 
entry, 


/* 


end  external  module  listing 


%reolace 


/*  codes  for  programmable  PIC  on  36/12  S3CJ 

note  that  icw2,icw4,  and  ocw  are  the  same   */ 


icwl_port_address 
icw2_por t_address 
icv4_pcrt_address 
ocw_port_address 


by  'c0'b4, 

by  'c2'b4, 

by  'c2'b4, 

by  'c2'b4t 


/*  note:  icw  ==> 


initialization 

control 

word 


ocw  ==> 


operational 

command 

word 


icwl 


by  '13'b4, 


/*  single  PIC  configuration,  edge 
triggered  inout  * / 


icw2 


by  '40'b4, 


/*  most  significant  bits  of  vectoring 

byte;  for  an  interrupt  5, 

the  effective  adiress  will  be 

(icw2  +  interrupt  # )  *  4  which 

will  be  (40  hex  +5)  *  4  = 

114  hex  */ 


ic  w4 


by  '0f  b4, 


/*  automatic  end  of  interrupt 
and  buffered  mode /master   */ 


ocwl 


by  '9f'b4, 
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/*  unmask  interrupt  5  (tit  5)  and 
rnaslc  all  others  * / 

/*  end  3259a  codes  */ 


true 

false 

vax 

clearscreen 


by  'l'b, 

by  '0'b, 

by  '7f'b4, 

by   z  ; 


/*  include  constants  specific  to  the  NI3010 
board  and  IP/TCP  declarations    */ 

%include  'vt.&cl'j 
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"be  sir.; 


,  J,  JL.  ,'-.  »»*  »',  .1,  . 


/::'   Main  ?ody  */ 
/*   initialize  the  ore  cess   */ 


del 


fill_xtpa(10000)  char  based{ trans_blk_ptr) J 


/*  disable  the  ni3010  so  that  it  does  not 
interrupt  this  initialization         */ 
copy_ie_regist er  =  disable_ni3010_inte rrupts ; 
call  write _io_port( inter rupt_enable_register, 

disable_ni3310_interrupts) ; 

call  read_io_port  ( command_status_register , 

reg_value ) ; 
call  perf orm_command (go_of f line  ) ; 

call  perf orm_command( reset  )  ; 

/*  clear  terminal,  tase  the  transmit  clock  and 
the  receive  block  in  the  extended  tpa,  and 
fill  the  tpa  with  asteriks.  */ 

put  list  ' cl earscreen  )  ; 
unspec f trans_blk_ptr )  =  '800l'b4; 
unspec(  rec_blk_ptr  )  =  '8630 'M; 
do  i  =  1  to  10000J 

fill_xtpa(i)  =  '*'; 
end  ; 


end; 


/*  initialize  the  pic   *  / 

call  wri te_io_port  ( icwl_port_address , icwl ) ; 

call  wri te_io_port  ( icw2_?ort_address  ,  icw2  ) ; 

call  wri te_io_port  ( icw4_port_address  ,  icw4  ) ; 

call  wri te_io_port  ( ocw_port_addres s  ,  ocwl  )  ; 

/*  end  initializing  the  pic   #/ 

call  initialize_cpu_inte rrupts ; 

call  initial ize_headers ; 

call  perf orm_ccmmand  (2o_online); 

call  perform_command'set_promiscuous_mode) » 

call  perform_command(clear_insert_source_address) ; 

/*  user  interface;  perforn  all  of  this  with  the 
board   disabled   so   that   the   i/o    runtime 
routines,  which  are  not  ^e-entrart,  will  not 
be  interrupted.  */ 

put  skip  list('how  many  messages  to  receive'); 

set    list  (user _desi res); 

call  make_ethernet_header; 

/*  end  initialization   */ 

S4 


/*  enable  the  "board  for  the  remote  login  */ 
copy_is_register  =  receive_blork_a vail  able  ; 
call  write_io_port  ( interrupt _enable_res;ist er  , 

receive_bIoclc_available)  I 
call  remote_login; 
call  perf orm_command  (reset); 

/*    end   main    body   */ 


/y*  ******  y-  y*  J<Jf  y*  *V  y*  *"  -1*  *■'»  -.'-  *'***-*«*  *i*y*  **-y*  *V*i#  V'  y»  »V  y-  •'*  V*  **"*'«  y-  y-  ***  y*  y*  y*  y*  ***  *•*  *"-  -.'--*»*  «i*  *<-  *v  J-  **-  -a*  .j*  y-  y*  ■»•*  y*  «L>  »u  *<-  *u  y* 

This  module  is  called  from  the  main  body  of  this  program. 
It  initializes  the  I?  and  TCP  headers,  the  Ethernet  frame 
type  filed,  and  several  other  variables  for  use  in  the 
remote  logn.  The  IP  header  source  and  destination  addresses 
are  the  addresses  of  the  VAX  and  Sun  on  the  ARPANET. 

<ju«Uh*/«>«  v.*y*  y-  y-  y»  *r"  o-  ^--  y-  .*.-.  y-  *j>  .*',  *>,  -i,  »<-  *<-  -'-  y**v  **-  «>*  *uy«  y*  o#  y»  y-»  y*  y*  y#yc  y*  y#  o-  y*  y>  a-  y*  *j*  y»  *»*  y*  y*  *>-  -■-  w--  ».i,  u»y*  y*  y*  »t*  a*    / 
i-  n*  *r  n*  *r  ^r  *r  *c  *i*  *P  v  n»  *r  *r  Jt*  7i*  -i*  -*»  i»  **-»*y  *r  ^r  *n  t*  f  •*»n*  "I*  *r  -v  ^*  *r  n*  -i-  t  -y*  t1  o>  n~  *p  f  *r  "V  7»*  "i*  *r  *i»  *i-  *r  "r  *r  *r  *»*  "»-  *r  'r  *r   / 


initialize  headers: 


procedure? 


/*  initialize  the  IP  header;  some  values  are 
completely  arbitrary  in  this  program;  for 
instance,  the  id  lsb  and  id  msb         */ 


unspec( int_hdr_ptr ) 

internet_ 

_header , 

.version_ihl  = 

internet. 

_header, 

. type_of _service 

internet. 

_header , 

.  len«2th_mst  = 

internet. 

_header , 

,ler^th_lsb  = 

internet^ 

"header . 

.  id  msb  = 

internet. 

_header, 

,id_lsb  = 

internet. 

_header. 

.flass  frag  = 

internet' 

"header, 

.  ttl  = 

internet. 

_header 

.protocol  = 

internet. 

_header, 

,hdr_ch°cksum  = 

internet' 

"header 

,source_a  = 

internet 

_header 

,source_b  = 

internet. 

_header , 

,source_c  = 

internet. 

_header , 

,source_d  = 

internet. 

_header 

,dest_a  = 

internet. 

_header , 

.dest_b  = 

internet' 

"header 

,dest_c  = 

internet 

header, 

.dest  d  = 

'800f 'b4J 

'45' 

'b4; 

'00' 

'b4J 

'00' 

'b4; 

'2c' 

'c4; 

'23' 

'Mi 

'4e' 

'b45 

'0000 'b4; 

'0f ' 

'b4» 

'06' 

'b4; 

'0000'b4J 

'c0r 

b4J 

'09' 

'b4; 

'c3' 

'b4J 

'01' 

'b4; 

'c0' 

'b4; 

'09' 

'b4; 

'c8' 

'b45 

'03' 

'M! 
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/*   initialize  the  TCP  header?  some  values  are 
completely  arbitrary;  for  instance,  the 

sequence  number,  source  port?  MOTS:  the 
source  port  will  he  stored  in  memory 
as  03  ff  hex  and  the  destination  port 
will  he  stored  as  02  01  hex.     */ 


unspec( tcp 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 
tcp_header 


_hdr_p 
sourc 
dest_ 
.of fse 
c  o  n  t  r 
windo 
windo 
check 
ursen 
data( 
da  tat 
data' 
data' 
data( 
data( 
seque 
seq  ue 
seque 
seo  ue 


tr)  = 
e_por t 
port  = 
t  = 
ol  = 
w_msb  = 
w_lsh  = 
sum  = 
t_point 

1)  = 

2)  = 

3)  = 

4)  = 

5)  = 

6)  = 
nce_num 
nce_num 
nce_num 
nee  num 


er 


(1)  = 

(2)  = 

(3)   : 

(4)  = 


'S023'b4J 

'ff03'b-rJ 

'0102'b4J 

'60 'b4; 

syn; 

'08'b4J 

'?0'b4J 

'0000 'b4I 

'0000 'b4; 

'02'b4J 

'04'b4J 

'04'b4J 

'00'b4; 

'30 'b4J 

'00'b4; 

'02'b4J 

'lc'b4J 

'23'b4J 

'01  'b4J 


do  i  = 


end; 


1  to  4J 
tcp_header  .ack_num  (  i  )  =  '00'b45 
inc_seq_num ( i )  =  '00'b4J 
seg_ack(i)  =  '00'b4J 


seg_len  =  '00 'b4; 

trans  mi t_d at a_ block. ty?e_field_a 
transmit_data_block. type_f ield_b 


'08'b45 
'00 'b4; 


end; 


initialize  headers  * / 
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/-i-    -J*  *<*   *,>'   ~'-   -J,    -Jr  »•*   <Jj.  -.»#   .Jj.  *'*    .'.,   ^'  -   O,  <Jo  -J*  ,»,   «X*   O-   *'*   Uj>  .'-    »l*   «.'.»    .1-   >!«.  »."   »'*   SV  %UU«iJ#NWtl«  «*'*  JL    JL»  V-   V-    -'-  »'*   *<..    «<«  ~J-   O*  »>*   wU   <bJ'   V*  »'  *    -'-  »t-  U«    v-   »>*   w   V 
*T  i*"t*  -*!*  '.-  *!■•  'i*  n*  '—  t  i*  "i*  -  *  *»•  -f"  t*  *i*  *i*  "t"*  *»-  'i"  n**v*  •»*  t*  *-'r  ^c  'r  *!*  n*  T"  «v  *r-  *,-  t*  "t-  *r  t*  *v  *>*  ***•  n*  '.»  *»*  i*  *i-  *i-  't*  *v+~r  i*  t  f*  *r  *■»*  *»**  nf* 

This  m o d u 1 s  is  called  from  various  other  nodules.  It  sends 
to  the  ii  130 10  board  the  command  receive!  in  the  parameter 
list.  It  then  waits  tc  see  if  the  command  was  cuccessfully 
carried  out  by  the  board.  If  the  command  was  not 
successful,  an  error  -nessage  is  displayed  and  the  program 
terminates . 

«*«  *J»   «.'-.  U#  tXm  *>-  JU  *>*  «l*  •>)<•   *Lr  ■*'*  «V    -'»  -'-  -'*  »••»  *'••  *•■»  *^*  -1'   J-   *■'«  ~*-   -JL'   -'*   -'-  -'-    -  '-  -J-  *>'-  -'-  •*"  -1-   -'-  »'*   -'-  -1-    -'-  »'*   »A,   »•*  O*  *i*   »l«  *l*  *t*  »',  sJ«   •>'*  -J*  -  '*    »'*  *.<-  -i-    .'-  »'*  -'-       / 

-;*  -v  -I-  *i*  «v  t  t*  *r  *p  *r  n*  ->-  -is  -.*  "i"  'i*  -v  *r  *r  n»  *.-  nr  *f»  *r-  *i*  *r  -.*  ***  f  Jr  n*  *r»  -v  *r  i*  *i*  -r  *>*  *">*  *p  *r  *i*  *»*  i*  '•*  *»*  i*  *i*  i*  *i*  n*  n*  <r  *»*  "i*  '•*  *i"  *•*   / 


perf orm_command : 


procedure  (command); 


declare 

command  bit  (S)  , 

reg_value  bit  (8)  , 

srf  bit  (8)  , 

write_io  port  entry  (bit  (8)  ,bit  (8)  ), 

read_io_port   entry  (bit  (8)  ,bit  .(6)  ); 


srf  =  '0'b4J 

call  vrite_io  port  (command  register, command); 

do  while  '(srf  &  '01 'b4)  =  '00'b4)J 

call  read  io  port  i'interrupt  status  reg, 

srf); 
end;   /*  do  while  */ 
call  read_io_port  (  co"nmand_status_register , 

reg  value); 
if  (reg  value  >  '01  'b4T  then 
do; 

/*  not  (SUCCESS  or  SUCCESS  with  Retries)  */ 

Dut  skio  edit  (  '***  ETHERNET  Board  Failure  ***') 
(col(35) ,a); 

stop; 
end;  /*  itd  */ 


end  perf orm_command 5 
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•  "V  T   *V*  "l* 


/->-  »'*  .»*  »•*  -■■-  V-  -  -  v>'  *,'-  »**  -  -  -.  -  -'*  *'«  -1-  «.''  »'>  «l«  •*!»  -.'-  w  -  %'»  . '»  v'*  ow  *.-  O*  ^_  .  '*  »'j.  *.'*  -  -  —  v-  •JL.  *■--  o_  -■..-*;,  v'-  _-  V  *■>"  »*-  -'•*  -'-  -'■'  •»'-  -'-  - 
*»*  *»*  'i*  i*  -r>  A'  "i**  *i*  "i*  *c  n*  *\H  "i"  *f  "1*  ->*  -i*  *i*  '.-  t  T"  *»*"r*  *p  *i*  *r*  *r*  *r  *i*  *V*  i*  *i*  *<"*  *i*  *i*  t*  *t*  'p  'i*  '»*  "i*  *i*  »i*  ■•.■*  f  *o  *i»  *i"  *i*  *o* 

This  -nodule  is  called  from  the  main  "body  of  the  program.   It 
nromijt s   the  user  for  the  destination  of  the   remote   losin. 


The 


Ethernet   address 


of 


the  Sun  is  used   as 


ne 


address  of  the  Ethernet  packet. 


:#!}:: 


source 


make_ethernet_header: 
del 


oroceaure  » 


choice  char ( 1 )  J 


choice  =     I 


do  while  (choice  _=  a  &  choice  _=  'b  & 
choice  ~=  'c '  &  choi'ce  ~=  'd'); 

put  skip  list 
('Chose  fron  helow  menu  the  destination  of  your  packet'); 

put  skip; 

put  skip  list 
('  NOTE:  enter'only  lower  case  letters'); 

put  skip; 

put  skip  edit 
('    a.   VAX  UNIX','    b.   SUNl')(a,skip,a ,skip); 

put  skip  edit 
('    c.   MYSELF','    d.   MPS') 'a, skip, a); 

put  skip; 

get   edit ( choice ) (a (1 ) ) ; 

put  skip; 
end;   /*  do  while  */ 


if  (choice  -  'a'  | 
do; 

transmi t_da  ta_ 
transmit_da  ta_ 
transmit_data 
transmit  data 
end; 
else 


choice  = 


choice  = 


do; 


transmit  _da ta_ 
transmit^  ata_ 
transmit  _data" 
transmit_data_ 
transmit _data_ 
transmit  _data^ 
nd; 


.  block. desti nation_address_a 

block.  iestination_address_b 

/block.destination_address_c 

"block  .  ies  t  inat  ion  address  d 


_hlock.destination_address_a 
block,  desti rati  on _address_b 
^block.destination_address_c 
"block.dest  inat  ion  _add  res  s_d 

block. desti rati  on _address_e 
block. desti nation  address  f 


then 

'02  'b4J 
'07  'b4J 

'01  'm; 
b4? 


'02'b4J 
'60'b4J 
'Sc'b45 
'00  'b4J 
'42'b4J 
'27  'b4; 
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if  choice  = 
do  ; 

transmi 
t  r  a  n  s  n  i 
end  ; 


l   t  h  e  r. 

_data_b lock. destination _address_e 
3ata  block. destination  address  f 


=  '07 'h4.: 


'7: 


)4J 


else  if  choice  =   c   then 
do; 

transmit_data_block  .des  tir.a  ti  on_address_e  =  '03'b4; 

transmit 2data_blcck .destinati on_address_f  =  'ea'b4J 
end; 
else  if  choice  =  'd  '  then 
do; 

transmit  _data_block  .dest  inati  on_address_e  -  '04'b4J 

transmit_data_block .dest ination_address_f  =  '0a'b4; 
end; 


trans  m it  _data_  block 
transmit_data_block 
transmit_iata_block 
trans  mi  t__data_block 
trans nit_iata_block 
transmit  data  block. source  address  f  = 


source_address_a  =  '02'b45 
scurce_address_b  =  '60'b4; 
source_address_c  =  '3c'b4; 
source_address_d  =  '00'b4; 
source_address_e  =  '42'b4J 

'27'b4J 


end;   /*  make  ethernet  header  */ 


,t*  -.U  O-  *Xm   V*  • 


This 
para 
pack 
IP/T 
numb 
bloc 
chan 
para 
with 
boar 

v»  »•-  «h>  *>- 

n*  1*  *i*  T* 


'  *i"  n^  *P 


<s  s^aeeaesxs 


modu 
ter 
to 

pro 

of 
S 
,   t 
ter 
a  bi 
s  lo 


me 
et 
C? 
er 

k. 
se 
me 

a' 


le   is  called  from  the  remote_login 
is  the  number  of  bytes  in  the  data  p 

be  transmitted,   i.e.   the  number  o 
tocols.    The  parameter  is  increment 
bytes  in  the  Ethernet  header  of  the 
hould   the   clear   insert   physical 
hen   it  should  be  incremented  by  8 

passed  is  a  fixed  bin '7);   it  must 
t  (3 )  variable  sc  that  it  can  be  writ 
w  byte  count  register. 

<J*  JU  Jf>  *J-  **-  */*  *.L*  *JU>  +.'*    -J-  s'-  -J*      O-  -1-  •»'-  -'-   -'-  -J-  ,  L,  „ '  -  ^1„  ..^  »*„  wi-  .-^  .J„  -J  •  »V  O*  -J'  V'  *'-*  -'«  >'■*  *.''  *'■ 

^x  ,,.,*,,,  „,  ,,»  ,, .  ^p  ,,,  n,  >r  ^ — r  -^  .,--,--,.  ^*  -,,  ,, .  ,,,  *p  ,,,  s,,  ,,,  ^»  ^  ^  ,,,  J,,  ,,„  ^  *,,  rfp  ^  ^» 


m  o  d  u  1 
ort  ion 
f  byte 
ed  by 
t  r  a  n  s  m 

addre 
vice 

be   o 
ten  o  u 


of 
s  i 
14, 
it 
ss 
14. 
ve  r 
t  t 


The 

the 

n  the 

the 

data 

mode 

The 

layed 

o  the 


:£:;: 


1*  T*  1*  T 


r  W  / 


transmi  t_packet : 

declare 

wri te_io_port  entry 
read  io  port  entry 


procedure  (lcw_byt_cnt 


(bit  (8)  .bit  (3)  ), 
(bit  (S)  ,bit  (3)  ), 


er.able_cpu_interrupt  s 


entry , 


/*  used  to  overlay  the  fixed  bin(7)  parameter  */ 
cnt  bit(3)  based ( byt_cnt_ptr) , 
byt_cnt_ptr        pointer, 
disable_cpu_interrupts        entry, 
low  byt  cnt  fixed  bin'7). 
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v  r i  t  s  _  ba r  entry  (pointer); 

call  di satle_cpu_interrupt s ; 

do  while  ( c opy_ie_regi ster  =  transmi t_dma_done 
copy_ie_regi ster  =  receive_dma_done) » 

call  enable_cpu_interrupts ' 

do  while  ( copy_ie_re^i ster  =  transmi t_dma_done 

i 

i 

copy_ie_register  =  recei ve_dma_dore ) ; 
end; 

call  di sable_cpu_interrupts ; 
end; 

copy_ie_regis ter  =  disable_ni3010  interrupts  J 
call_write_io_port{interrupt_enahle_register, 

disable_ni3v*10_interrupts  ) ; 

call  enable_cpu  interrupts; 

call    write_bar   "Taddr  ( t  ransmi  t_da  ta_b  lock  )  )  I 

call  write_io_pcrt ( high_byte_count_reg ,  '00't4l ; 

/*  increment  the  parameter  and  overlay  it  */ 
low_byt_cnt  =  low_byt_cnt  -  14; 
byt_cnt_ptr  =  addr ( low_byt_cn t ) ; 
call  write_ic_pcrt(low_byte_count_reg, en t ); 

call  di sat le_cpu_interrupt s ; 

copy_ie_regis ter  =  transmi t_dma_done ; 

call  write_io_port(interrupt_enable_register , 

transmi t_dma_done); 
call  enable_c pu_interrupt s ; 

do  while  f copy_ie_regi ster  =  transmi t_dma_done ) ; 
end;    /*  loop  until  the  interrupt  handler 

takes  care  of  the  TCP  interrupt  - 

it  sets  IE_RES  to  4  */ 

call  perf orm_ command (load_and_send) ; 


end  transmi t_packet ; 
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EL  interrupt  randier: 


procedure  external; 


declare 

source  bit (8)  external, 

wri te_io_port  entry  (bit  (3)  ,bit  (8^ 

read_io_port  entry  [bit  (3)  ,  bit(S) 

enable_cpu_interrupts         entry, 

user_desires  fixed  external, 

di  sable_cpu_in ter rupt s        entry , 

write  tar  entry  (pointer); 


), 


), 


call  disable_cpu_interrupt s ; 

call  write_io_port(interrupt_enable_register, 

disable_ni 30 10_inter rupts ); 
if  ( copy_ie_register  =  receivp_block_available ) 
then  do; 

/*  gives  address  to  board  for  next  dma 
of  packet  into  memory  * / 

call  wri  te_bar '  addr ( recei ve_data_ block) ); 
call  wri te_io_Dort (high_byte_count_reg,  '06'b4); 
call  write_io_port(low_byte_count_reg, '00 'b4) ; 

/*  initiate  receive  DMA  */ 

copy_ie_regist er  =  receive_dma_done ; 
call  write_io_port(interrupt_enable_register, 

recei ve_dma_d one) ; 

end;    /*  if  receive=block  available  */ 
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elsi 


if  (co"Dyie_rsgist2r  =  recei ve_d ma  done)  then 
do »' 

numher_of _packet s=numcer_of _packets  +  l; 

size_ptr=  addr(receive_data_"block.f  rame_length_lsb  )  5 
if  (size  >  1522  !  size  <  64)  then 
d  o  ' 

'put  skip  listC'SIZE  ERROR'); 

stop; 

end ; 

source  =  '00'b4; 

If   ( receive_data_block .  source_a1.dress_f  =  vax)  then 
do; 

source  =  vax; 

do  i  =  1  to  41 

se£_ack(i)  =receive_data_block.data (i  +  24); 
end ; 
end; 

rec_blk_ptr  =  adir  ■'  recei  ve_iata_olock.da  ta  (  s  ize-4=)  ) ; 
copy_ie_regis  t  er  =  recei  ve_block_availa ble  ; 
call  write_io_port  '  interrupt _enatle_register, 

recei ve_block_available); 

end;   /*  if  receive  dna  done-*/ 


else 
if 


(copy_ie_regis ter  =  t ransmi t_dma_done ) 
then  do; 

copy_ie_regis t er  =  receive_block_available; 

call  write_io_port  'interrupt_enable_register , 

receive_block_available); 

end;    /*  if  transmit  dma  done  */ 


end  HI  interrupt  handler; 
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calc_tcp_cksum : 


procedure ; 


del 


cksum   entry  (bit  (8) , fixed  bin( 7  )  ,oi t ( 16 ) ) , 

fixed_overlay   bit(9)  based (f ixed_overlay_ptr ) 

f ixed_overlay_pt r    pointer, 

int_length   fixed  bin(7)  based ( int_length_otr) 

int_length_ptr   pointer, 

numl6bit_wds     fixed  bin(7), 

odd    bit(l),   /*  odd  IP  length  */ 

temp (13)   bit (9); 


odd  =  false; 

do  i  =  1  to  12;   /*  save  last  12  bytes  of  I?  header  */ 

temp(i)  =  trans"ni  t_data_block  .da  ta  (  i  +  5); 
end; 


/*  form  tcp  PSTJDO  HSADEP  */ 


tran 

tran 
tran 
tran 
tran 
tran 
tran 
tran 
tran 
tran 
tran 


smi  t 
smi  t 
smi  l 
s  m  i  t 

smit 
smi  t 

smi  t 
smi  t 
smit 
smit 
smi  t 


_data 
.data 
^data^ 
_data 
data 
da  ta 
_ia  ta 
_data 
^data' 
_data 
'data 


block 
block 
block 
block 
block 
'block 
block 
block 
^block 
block 
block 


.data(9) 
.data (10) 
.data( 11) 
.data(12 
.data(13 
.data(14 
.data (15 
.data  (16 
.data(17 
.data  ;i9 
.data(19 


'c0'b4,* 
'09'b4; 
'c9'b4; 
'01  'b4J 

'c£'b4; 
'09'b4; 
'c9'b4,* 
'23'b4J 
'00'b4? 
'06'b4; 

'?0  'm; 
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/*  overlay  bit(S)  with  fixed  value  */ 
int_l.ength  ptr   =  addr (internet_header .length_lsb ) > 
seller  =  rint_len,srth  -  20^; 
numl6cit_wds  =  divide( (int_length  -  a), 2, 7); 

/*  check  if  length  is  odd  number  of  bytes  */ 
if  (  nod(seg_len  ,2)  "=  0  )  then 
do ; 

old  =  true; 

numlobit_vds  =  numiebi t_wds  +  1! 

temp(13)  =  transmit_data_tlock.data  (  int_length  +  1); 

transmit  data  "block  .data (int_length  +1)  =  '00'b4; 
end; 

/*  insert  byte  12  of  pseudo  header  */ 
fixed_o verlay_ptr  =  addr ( seg_len ) ; 
transmi t_data_block .da ta ( 20 )  =  f ixed_over lay ; 

call  ck sum (transmit _data_block.data(9)  , 

numl6bit_vds,tcp_header.  checksum ) ; 

/*  restore  I?  ;|J? 
do  i  =  1  to  12; 

transmit_data_block.data ( i  +  8)  -   temp(i); 
end; 
if  odd  =  true  then 

transmit  data  block. data ( in t  length  +1)  =  temp(13); 


end  calc_tcp_cksum> 


remo te_login : 


procedure ; 


declare 

source  bit(S)  external, 
packet_length  fixed  bin(?)  external, 
add32bit  entry  ( bit ( 9  )  ,  bit ( S) ,bit (a ) ) , 
cksum  entry  ( bi t ( 3) , f ixed  bin (7 ) , bi t ( 16) ) , 
wri te_io_port  entry  (bit  (8)  ,bit  (S)  ), 
numiebit  vds  fixed  bin(7)  external; 
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/*   send  packet  1  */ 
numi6bit_wds  =  10 ', 

call  c_  sun  (interne  t_header.version_i  hi  , rumlcbi  t_wis  , 

intern et_he a der . hdr_checksum  ) ; 
call  calc_tcp_cksu.m? 
packet_length  =  46; 
call  transmit_packet(packet_length); 


/*  assume  VA.X  will  acknowledge  it  #1  ,  wait  until  it  does  */ 


do  while 
end; 


source  ~=  vax  ) » 


/*   packet_2  update   */ 

inc_sea_num (4 )    =    '31  'b4; 

call   add32bit  ;'  tcp_header  .  sequence   num(4)  ,  inc_seq_num  (4)  , 

tcp_header. seauence_num (4)  )  I 
tcp_header . of f set  =  '50'b4J 
tcp_header.cor.trol  =  ack; 

call  add32bit ;seg_ack( 4) , inc_sea  num (4 ) , tcp_header .ack_num(4) 
internet_header.lenetb._lsb  =  '23^b4; 
internet  header. id  lsb  =  '02'b4J 


/*     eni    packet_2   update      */ 

numl6bit_wds  =  10J 

internet_header .hdr_checksum=    '0000'b4; 

call  cksum (inter net_he ad er. version _i hi, numl6bit_wds, 

internet _header .hdr_c heck sum  )  5 
tcp_header . checksum  =  '0000 'b4J 
call  calc_tcp_cksum; 
packet_length  =  46; 
call  transmit_packet(packet_length); 


/*  packet  3  update  */ 

internet_header.length_lsb  =  '29'b4? 
tcp_header .control  =  ack  psh; 
tcp_header  .data  (1 )  =  '00  "*Mt 
tcp_header.da ta(2)  =  '04'b4J 
tcp_beader .data (3)  =  '04'b4J 
tcp_header .data(4)  =  '00 'b4I 
tcp_header .data(5)  =  '00 'b4; 
tcp  header .data(6)  =  '00'b4J 
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internet_header . id_lsb  =  '33'b4J 

numl6bi  t_wds  =  10  5 

i  rterne  t_head  er  .hdr_checksum  =  ' ? C i? 2  ' b 4  J 

call  cksum(  internet _he ad er.version_i ill  ,numl6bi t_wds  , 

internet _header .hdr_checksum) ; 
tcp_header  . checksum  =  '0000'b4» 
call  calc_tcp_cksum; 

packet_length  =  45  > 

call  transmit_packet(packet_len£th); 


/*  packet  4  update  */ 

interne t_header .length_lsb  =  '2e'b4; 
inc_seq_num  '4  )=  '0l'b4J 

call  add  32  "bit  '  tcp_header . sequence_num(4)  , inc_seq_num (4)  , 

tcp_header . sequence_num( 4 ) ) J 

tcp_heaier.data (1)  =  '72'b4; 

tcp_header  .data  (2)  =  '65'b4J 

tcp_header .da ta (3 )  =  '65'b4; 

tcp_header .da ta ;4)  =  '6b'b45 

tcp_header .data (5 )  =  '65  'b4; 

tcp_header.data(6)  =  '00'b4J 

interne t_header . id_lsb  =  '04'b45 

numl6bit_vds  =  10  ? 

interne  t_header  .hdr_checksum  =  '0000'b4>' 

call  cksum( internet _header. version _i hi ,numl6bit_wds, 

internet _h eader.hdr_checksui m  ) J 
tcp_header . checksum  =  '0000'b4J 
call  calc_t cp_cksumJ 
packet_lensth  =  46; 
call  transmit _packet(packet_len^th)J 


/*  segment  5  update  */ 

inc_seq _num ( 4  )=  '06'b4J 

call  add32bit ( tcp_header . seauence_num(4) ,inc_sea_num\4) , 

tcp_header  .  sequence _num (4 )) » 

interne t_header . id_lsb  =  '05'b4J 

numl6bit_wds  =  10> 

interne t_header .hdr_checksum  =  '0000'b45 

call  cksum ( internet _header . vers  i on _i hi, n urn 16bit_wds, 

internet _header .hdr_c heck sum ) ; 
tcp_header  .  checksum  =  '000O'b4>* 
call  calc_tcp_cksum ; 
packet_length  =  46; 
call  transmit_packet(packet_length)J 
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/*  packet  6  update  */ 

interne  t_header .length _lsb   ='31  'b4 ; 

inc_seq_rum  (4  )  =  '06'b4> 

call    add32bit  ( tcp_header . sequence _nurc( 4)  ,  inc_sea_nurn  (4)  , 

tcp  header . sequence_num (4 )) » 
internet   header. id   Isb   =  '06''b4; 


tcp 
tcp^ 
tcp. 
tcp. 
tcp^ 
tcp. 
tcp' 
tcp^ 
tcp. 


_header 
"header 
_header 
_header 
"header 
header 
^header 
_header 
header 


.data(l) 
.data(2) 

.data (3) 
.data(4) 
. data (5) 
.data(6) 
.data(7) 
.data(8) 
•  data(9) 


'73 
'75 

'6e 
'2f 

'39 
'36 
'30 

'30 
'00 


'b4J 

'o4; 

'm; 

'b4J 
'b4J 

'14; 

"b4J 

'd4; 


numl6bi t_wds  =  12 i 

interne  t_header  . hdr_ch.ecksum   =    '?003'b4; 

call  cks urn ( internet _he ad er. vers i  on _i hi, numl5bi t_wds 

internet_header .  hdr_checksum ) ; 
tcp_header  .checksum  =  '0?00'b4; 
call  calc_tcp_cksum; 
packet_length  =  49; 
call  transmit_packet(packet_len£th) ; 


/*  wait  unti  vax  replies  */ 


do  while  (source  ~=  vax); 
end? 


/*  wait  until  vax  replies  with  its  null  byte  */ 

do  while   (   (source  =  vax)  S. 

( receive_data_block.da ta (34)  ~=  ack_psh)  ); 
end; 


/*  packet  7  update  */ 

interne t_header . length_lsb  =  '2S'b4J 

inc_sea_num(4:  )  =  '09'b4; 

call  add32bit( tcp_header .sequence_num(4) ,  inc_seq_num (4 ) , 

tcp_header .seauence_num(4)); 
inc_seq_num (4  )  =  '01  'b4J 
call    add32bit (tcp_header.ack_num(4) ,inc_sea_num(4) , 

tcp_header .ack_num(4 ) ) ; 
tcp_header .control  =  ack; 
internet  header. id  lsb  ='07'b4; 
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tcp_header  .data ( 1 ) 
tcp_header .data  f 2) 
tcp_header .da  ta(3) 

tcp_ header. data  .4) 
tcp_header.dataf5) 
tcp_header .da  ta  ;6  ) 


=  '2f'"b45 
='39'b4J 

='36'b4; 
=  '30"b45 

='30'b4; 
='00'b4; 


r.uml6bi  t_wds  =  10> 

internet~header .hdr_checksum  =  '0000'b4> 

call  cksum( internet _header. vers ion_ihl,numl 6b i t_  wds , 

inter net_header.hdr_checks urn) ; 
tcp_header .checksum  =  '0000 'b4; 
call  calc_tcp_cksum; 
packet_length  =  46? 
call  transmit_ packet (packet_length) ; 


put  skip  list  ('PACKET  *7  SENT'); 

put  skip; 

do  while  ( number_of _packet s  <  user_desires  )? 

end;  /*  dc  while  */ 


end  remo te_login; 


end ; 
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APPENDIX  E 


SOURCE  CODE  EOF.  32  SIT  ADDITION 

EXAMPLE  CF  CALL  TO  TEIS  PROCEDURE 

call  add32M t (numberl (4 ) ,number2(4) , result (4) )  where: 

parameter  1  is  the  least  significant  byte  of  a 

32bit  number  (array  cf  4  bytes) 

parameter  2  is  the  lsb  of  another  32  bit  number 

parameter  3  is  the  lsb  of  the  result 


The  32  bit  numbers  are  stored  in  memory  such  that  the  high 
order  byte  occupies  the  lowest  memory  location.   This  is 
contrary  to  the  way  that  PL1  stores  numbers.   The  numbers 
are  stored  in  this  manner  because  they  have  been  DMA'd 
into  memory  by  the  NI3010  board  in  the  order  they  were 
recieved  over  the  Ethernet,  i.e.,  high  order  byte 
recieved  first . 

The  algorithm  adds  the  numbers  byte  by  byte  starting  with 
the  low  order  bytes  and  places  the  rseultant  byte  addition 
into  the  corresponding  result  byte  position. 


public   add32bit 


add32bit: 


cseg 

push  ax!  push  bx!  push  ex!  push  dx !  push  si!  push  di  ' 


mov 

mov 
mov 
mov 

clc 


ex ,  04h 

si , [bx] 
di,2[bx] 
dx ,  4  [bxl 


J  number  of  bytes  to  be  added 

;  (32  bit  number) 

Jload  index  registers  with  address 

♦the  lsb  of  each  number  to  be  added 

Jpointer  to  the  lsb  of  the  result 
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bes: 

710  V 

al,  [sij 

710V 

ah,  [di] 

adc 

ah  ,  al 

dec 

si 

push 

si 

mov 

si  ,dx 

mov 

[si]  ,ah 

dec 

si 

mov 

dx  ,si 

pop 

si 

dec 

di 

loop 

"beg 

•byte  of  first  number  to  add 
tbyte  of  other  number  to  add 

♦decrement  pointer  and  store  it  away 

♦make  si  now  point  to  result 
Imove  addintion  into  result 

•'step  down  in  memory 
Jsave  pointer  to  result 


pop  di!  pop  si!  pop  dx !  pop  ex!  pop  bx !  pop  ax  I 
ret 
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APPENDIX  F 


CHECKSUM  PROGRAMMING  NOTES  AND  SOURCE  CODE 

The   checksum  algorithm  for  the  IP  header  and   the   TCP 

segment   are  the  same.    The  official  specification  for   the 

algorithm  is: 

The  Checksum  field  is  the  16  hit  one's  complement  of 
the  one's  complement  sum  of  all  16  hit  words;  for 
purposes  cf  computing  the  checksum,  the  checksum 
field  is  zero  .  [Ref .  3] 

Another  source  lists  the  algorithm  as: 

The  checksum  field  is  to  simply  add  up  all  the  data 
regarded  as  16  bit  words,  and  then  to  take  the  one's 
complement  of  the  sum.  [Ref.  6] 

The   assembly  language  program  below  always  agreed  with   the 

checksum   calculations   that  were  contained  in  the   packets. 

Initial   attempts  yielded  inconsistent  reults  when   compared 

to  those  in  the  UNIX  produced  packets.   Some  attempts  always 

proiuced  the  correct  result  for  the  I?  header  and  92%   of  the 

time   for   the   TCP  header.     Other   attempts   were   less 

consistant  than  the   above  example.    Since  one's  complement 

arithmetic   is   used,    the   erroneous   implementations   can 

produce   results   that  are  auite  close  to  those  produced   by 

the  UNIX  operating  system. 

The  program  below  implements  the  algorithm  as  if  the   16 

bit  words   were  integers  stored  with  the  least   significant 

byte  in  low  memory,   followed  by  the  most  significant   byte. 

Note  that  the  first  byte  of  the  word  is  loaded  into  the   low 
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side  of  the  15  tit  registers  in  the  8086  micro-processor  and 

the  second  byte  loaded  into  the  high  side  of  the  registers. 

EXAMPLE  CF  CALL  TO  THIS  PROCEDURE 
call  cksum (x ,y, z)  where: 

parameterl  (hit  (8))   is  the  starting  byte  of  data 

to  he  summed 
parameter2  (fixed  bin  7)  is  one-half  the  length  of 

the  block  {ft   of  15  tit  words) 
parameters  (Mt(16))   the  resultant  16  tit  checksum 

; The  dx  register  will  contain  the  resultant  checksum. 


public   cksum 

cksum: 

cseg 


push  ax!  push  tx !  push  ex!  push  dx !  push  si! 

Jload  ex  with  one-half  the  length 

Jzero  cut  high  side  of  ex  register 
Izero  out  running  total  of  checksum 

J  si  points  to  first  byte  of  tlock 


;mst  of  16  bit  word 

;lsb  of  16  bit  word 
Jadd  to  running  total 


mov 

sit2[bx] 

mov 

ex,  [si] 

mov 

ch,00h 

n0V 

dx,0000h 

mov 

si,  [bx] 

clc 

again : 

mov 

al.Csi] 

inc 

si 

mov 

ah,  [si] 

adc 

dx  ,ax 

inc 

si 

loop 

aga  in 

xor 

dx,0ffffh 

mov 

si  ,4[bx] 

mov 

[sil ,dl 

inc 

si 

J'l's  complement  of  running  total 
Jplace  result  in  return  parameter 
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mov      [si]  ,dh 

pop   si!  pop   dx !  pop   ex!  pop   dx  !  pop   ax! 
ret 
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APPENDIX  G 

INCLUDE  FILE  FOR  PROGRAM  LISTEN 

^replace 

/*  I/O  port  addresses 

These  values  are  specific  to  the  use  of  the  INTERLAN 
NI3010  MULTIBUS  to  ETHERNET  interface  board.  Any 
change  to  the  I/O  port  address  of  '2?tQ'   hex  (done 
so  with  a  DIP  switch)   will   reauire   a  change  to 
these   addresses   to  reflect  that  change. 

*/ 


commar.d_regi  ster  "by  'b0'b4, 

command_s tatus_register  "by  'bl'b4, 

transmi  t_data_resister  "by  'b2'b4, 

interrupt_status_ree  by  'b5'b4, 

interrupt_enable_resis ter  by  'b8'b4, 

high_byte_count_reg  by  'bc'b4, 

low_byt e_count_res  by  'bd'b4. 


/*   end  of  I/O  port  addresses  */ 

/*   Interrupt  enable  status  regis 
disable _ni 30 10 _interrupts 
ni3010_intrpts_disabled 
receive _b lock _available 
transmi  t_dma_done 
receive  d  m  a  done 


/*   end  register  values  */ 

/*   Command  Function  Codes  */ 

module_interf ace_loopback  by  ^01^b4, 

internal_locpback  by  '02'b4, 

clear _1 oop back  by  '03'b4, 

go_offline  by  '09'b4. 

go_online  by  '39'b4, 

onboard_diagnost ic  by  '0a'b4, 

load_transmit_data  by  '28'b4, 
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r   values   * 

/ 

by 

'00' 

04, 

by 

'00' 

'H4, 

by 

'04' 

'b4, 

by 

'06' 

'b4. 

by 

'07' 

'w, 

lcad_ar.d_serd 

reset 

set_promiscuous_mode 

clear  insert  source  address 


by  '29 'M, 

by  '3f'b4, 

by  '04'b4, 

by  '0e'b4J 


/* 


end  Command  function  Codes 


*/ 
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APPENDIX  H 


INCLUDE  FILE  FOE  PROGRAM  DEMO 


decla  re 


internet_header 

2  version_ihl 

2  type_of _servi 

2  length_msb 

2  lenstb_lsb 

2  id_msb 

2  id  1st 

2  flags_frag 

2  ttl 

2  pro  tocol 

2  hdr_checksum 

2  source_a 

2  source_b 

2  source_c 

2  source_d 

2  dest_a 

2  dest_b 

2  dest_c 

2  dest  d 


based ( in t_hdr_ptr ) , 

bit(8) , 
:e    bit  (3), 

bit(8) , 

bit(S) , 

bit(8) , 

bit(8) , 

bit  (16-)  . 

b  i  t  ( 8 ) , 

b  i  t  ( 3 ) , 

bit (16)  , 

bit(8) , 

bit(8)  , 

bit(8) , 

bit(3)  , 

bit(3) , 

bit(S) , 

bit(3) , 

bit(8)  , 


1   tcp_header  based( tcp_bdr  ptr; 

source_port  bitTl6), 

des t_port  bit (16)  , 

sequence_nurn(4 )  bit  (3) 

ack_num(4)  bit (3) 

offset  bit  ('S) 

control  bit (8) 

window_msb  bit(S) 

window_lsb  bit (3) 

checksum  bit(16) 

urgent_pointer  bit(16) 

data(512)  bit(8). 


2 
2 

2 
2 

2 

2 

£ 

2 
2 

2 
2 


int_hdr_p tr 
tcp_hdr_ptr 
seg  len 


pointer, 
pointer  , 
fixed  bin(7)  , 
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'*   These  4  element  arrays  are  32  "bit  variables    */ 

inc_seq  num(4)   bit(8), 

seg_ackT"4)      bit(8); 

%replace 

/*  Control  bit  for  the  TCP  header   */ 

ack  by  '00010000'b, 

ack_psh  by  '00011000 'b, 

syn  by  '00000310 'b, 

ack_fin  by  '0001000l'b, 

ack_syn  by  '00010010  'b  , 


/*  I/O  port  addresses 

These  values  are  specific  to  the  use  of  the  INTSRLAN  NI3010 
MULTIBUS  to  ETHERNET  interface  board.  Any  change  to  the  I/O 
port  address  of  '00b0 '  hex  (done  so  with  a  DIP  switch)  will 
require  a  change  to  these  addresses  to  reflect  that 
change . 

*/ 


command_regist er 
command_s ta tus_regi ster 
transmit_data_ register 
interrupt_status_reg 

interrupt  _e.nable_  register 

high_byte_count_reg 

low_byte_count_reg 

/*  end  of  I/O  port  addresses  */ 


/*   Interrupt  enable  status  register  values  */ 

disable_ni3?10_interrupts 
ni3010_intrpts .disabled 

receive _block_available 

transmit_dma_done 

receive_dma_done 

/*   end  register  values  */ 
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by 

'b0'b4, 

by 

'bl'b4, 

by 

'b2'b4, 

by 

'b5'b4, 

by 

'b3'b4, 

by 

'be 'b4, 

by 

'bd'b4, 

by 

'00'b4, 

by 

'00'b4, 

by 

'04'b4f 

by 

'06'b4, 

by 

'07'b4, 

/* 


ommar.d  Function  Cedes  */ 


module_interface_loopback 

internal_loopback 

clear_l oopback 

go__offl  ine 

go_online 

onboard _dia gnostic 

load_transmi  t_data 

load_and_send 

reset 

set_promiscuous_mode 

clear  insert  source  address 


by 

'0l'b4, 

by 

'02'M, 

by 

'03'b4, 

by 

'08'b4, 

by 

'09'b4, 

by 

'0a'b4, 

by 

'28  "b4, 

by 

'29'b4, 

by 

'3f 'b4, 

by 

'04'b4, 

by 

'0e'b4J 

/* 


end  Command  Function  Codes 


*/ 
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